framstag / libosmscout Goto Github PK

Hi Tim. When I am playing with map, I often see row of building simplified to triangles. You can see it in this screenshot:

Here with closer zoom:

How complex would be to merge these areas that are sharing more than one point into one before optimize step? I think that this kind of optimization should reduce number of geometries in city areas and produce smaller database...

Allow configuration of an initial offset for shapes on lines

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Such imports will fail on assert that we are able to store only 19 valid bytes from nodeSize #96

This problem is real, some old Wales (UK) OSM extracts are failing because of that problem. We discuss it in mail thread: https://sourceforge.net/p/libosmscout/mailman/message/35293165/

The build fails with the following error:

[ 99%] Swig source /home/mm/Projektek/jolla/libosmscout/libosmscout-binding/../libosmscout/include/osmscout/TypeConfig.h:265: Warning 325: Nested struct not currently supported (TypeCondition ignored) /home/mm/Projektek/jolla/libosmscout/libosmscout-binding/../libosmscout/include/osmscout/TypeConfig.h:875: Error: Syntax error in input(3). make[2]: *** [libosmscout-binding/CSharp/libosmscoutCSHARP_wrap.cxx] Error 1 make[1]: *** [libosmscout-binding/CMakeFiles/osmscout_binding_csharp.dir/all] Error 2 make: *** [all] Error 2

OS: Ubuntu 14.04.5 64 bit
cmake 3.5.2 from this PPA: https://launchpad.net/~george-edison55/+archive/ubuntu/cmake-3.x
(I do not think it is matters)

Libosmscout used a number of (std and std c++11) container classes that are currently not directly support by SWIG. These thus have to be added by libosmscout itself to allow more access from Java to the libosmsocut APIs.

Please implement such container wrappers.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

To evaluate the effect of caching of render specific data in regard to render performance and memory consumption an initial proof of concept should be done:

• Add another Draw method that either gets concrete tiles passed or the MapService (so it can request tiles on demand itself).
• Implement a cache, that allows assignment of one or one per object type structs to a tile id in the cache.
• Implement a simple API to allow a specific renderer to extend the data stored for an object type by its own custom information.
• Create one or multiple data objects for caching as much as possible information for a node. Such information could be: One or multiple resolved label and symbol styles including label data, dimensions and positions.

In the first step Information should be stored projection on on-screen position independent. Before drawing only the following steps should be required to be done:

• Transform geo location of the node to an on screen coordinate
• Evaluate the label in relation to other labels resulting in "visible" or "not visible"

In a second step one could already evaluate visibility based on the other labels within the same tile.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Currently you can visit areas via the Projection class, where the mercator projection is not defined. This may likely be the case for other projections, too.

Improve the current API so that either the client is informed about the problem or some "snap back" or "auto correct" mechanism ensures that the selected area is always "defined".

The current API for handling OSM Tiles (libosmscout osmscout/util/Tiling) can be improved:

• A type for OSM Tile number should be defined - currently size_t and int are both used.
• Perhaps we should wrap the stuff in some nice classes?
• Documentation should be enhanced (link tot he official OSM document).
• It should be made clear, that there is a difference between OSM Tiles and the tiles libosmscout uses internally at various places.

The WaterIndex for germany/nordrhein-westalen ist still rather big, though this area does not have any coastlines or water at all (please proof this claim). We should make sure that such (not so) corner cases are detected and no bitmap is stored at all but a shortcut is implemented in this case.

To improve the rendering for physical ways that consist of multiple OSM ways, these ways should be joined by the renderer and labels should be rendered on top of joined line. This avoids irregular spacing of labels in this case.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

This proof of concept should take neighbouring OSM export from the same provider and realise the following tasks:

• Check that identical notes on the border are provides in both imports and have the same id
• Count the number of such route nodes that do exist in both imports (estimation for the size of a hash map that holds such "special case" ids).
• Find a cell size for an index that covers such border regions that hold "special interest" route nodes.
• Estimate which of the to approaches does require less memory,is more performant during runtime and does require less pre-routing processing.
• Add an abstracting/extention to the existing data structures that handles the lookup of nodes in multiple databases.
• Do some routing and performance tests.

Some backgound from one of my mails in response to above topic:

There is currently no code that allows this. However the recent change
so that nodes (as part of ways or areas) and route nodes have an id
that is unique independent on the actual import allows in principle to
look for a specific route node in multiple databases.

There are of course some pre requirements:

• The unique id is generated based on the coordinate. If different
  imports have different resolution of the coordinate the same node may
  get a different unique id.
• The imports needs to have all nodes for the same coordinate since
  the unique id is based on the coordinate and a running number per
  coordinate.
• The imports must overlap. That means that a way or area in the
  "border" must be available in both imports - or at least one node. So
  I route to the "end" of the database, then lookup for the same route
  node in the next database and continue the routing there.

You also need some kind of index that tells you which nodes you have
to look for in multiple databases, since there is no "look in other
databases, too"-maker. Such index could either be based on a
cell-approach (this cell is in the following databases...) or based on
the actual ids (this id is in multiple databases).

In this case we get some "cannot create file" error for types.dat which does not hint at the actual problem. Better to test for the existance of the target directory before starting the import and put out a better error message in this case.

The current (new) web site looks rather fine on desktop systems but I assume that the appearance on mobile devices can be optimized.

I would suggest to add some media queries to the style sheet to change sizes and layout in the case of mobile devices. Also the menu should be changed to a popup/slide in menu to safe space.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

It can be reproduce with Ubuntu docker image from this branch: https://github.com/karry-space-with-my-second-forks/libosmscout/tree/docker-bindings-github

git clone -b docker-bindings-github  https://github.com/karry-space-with-my-second-forks/libosmscout.git libosmscout
cd libosmscout/ci/docker/ubuntu_16.04_gcc_cmake
./build.sh
./run.sh

Allow defining labels drawn on the area border (either on the border, within, or on the outer side). See also the "multiple borders for areas" issue (this can possibly be combined).

Issue #56 should be implemented first. Rendering of contour labels on area borders will not make sense before.

We are now able to define any number of internal "fake" types. These are types that do not exist in OSM itself but are purely defined by libosmscout for artificial like water/land cells, the current route, the equator or similar. We use a internal type, because the style sheet allows easy filtering based on types and thus it is easy to assign style sheets to such types.

We should however make sure, that the services do not try to load data from one of the indexes for such type. While the indexes should not find any data for these types the index might still require more ressources than necessary.

Tasks:

• Test if the problems exists
• Make type identifyable (if not yet possible)
• Add filtering at a central code location

See topic

For area border labels (and possibly in some situations also for ways) it makes sense to draw them with some relative offset to the actual path.

We did some recent changes in the MercatorProjection leading to the effect that the "resolution" for the resulting map seems to be higher, the map context more crowdy.

As a result the style sheet should be adapted, that "things" are drawn later, this means at an higher resolution than currently.

Side effect: Rendering gets faster.

Manual style sheet optimizations show, that an explicit tool may be helpful:

Features of the tool:

• Analysis of actual data: Which types in the database will be visible at which zoom level. If style will try to draw the type from a lower zoom level, output some warning. Example: Do not draw buildings at state level, they will not be visible at all.
• Analyse for each zoom level the amount of nodes drawn to visualize data by type. Hint at types, that have many nodes and are expensive to render.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

While rotating the map in demo application OSMScout (Qt, qml), some objects in the map may disappear depending on angle. Below few screenshots for demonstration.

In this case, river and some buildings not rendered in some range of angles.

LocationService allows to describe a geo coordinate in relation to objects in the database.

In this case describe a coordinate in relation to a nearby POI.

Example:
"30m meters north top Rewe shop".

For rendering the bounding box is defined as min-max in both directions.

Since the mercator projection is not defined for 90 lat anyway navigation around this coordinate is not a problem. But it is assumed that rendering over the 180/-180 "line" will result in strange effects since the switch is not correctly handled and the resulting bounding box is faulty.

Write a test case, identify broken code and fix it.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Hi, Thanks for your great project.

I am going to test your demo project in iOS but have lots of issues that I couldn't solve myself.
After I manually install dependent libraries on Mac OSX, I tried to open and build OSMScoutiOS Xcode project.
I notice that there are two missing files marisa.h and TypeSet.h, but can solve this by copying files.

The critical issues are happening in OSMScout.mm

mapPainter = new osmscout::MapPainterIOS(styleConfig);

This line says the no matching constructor for initialisation and show 9 errors.

Can you help me to solve this issue?

Or if you have any iOS building guide, it would be helpful.

Thanks in Advance

Currently only simple areas are actually merged. Support merging of more complex (multiple rings) areas, too.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

IMHO street name at address and for the street itself must match exactly. However at least in some countries this is not the case, matches are only case insensitive. Reason is: Imports do not follow mapping guide lines.

Optionally generate a warning in this case. This would be especially helpful if generating HTML reports.

If the check is expensive, make it possibly optional (or only if warnings are logged).

Dump the ground tile map first and afterwards the bitmap. This way we can determine the disk size of the ground tile map, can calculate the number of bytes we need to address cells in it and thus can reduce the number of bytes to store an individual cell index (instead of using always FileOffset).

For doing more fancy rendering allow rendering of additional area borders with negative/positive offset (similar to ways).

To allow multiple borders AREA.BORDERTEXT and AREA.BORDERSYMBOL have to be enhanced with the slot mechanism.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Hi tim, I want to add "where am I?" functionality to OSMScout for Sailfish. I tried to use DescribeLocation demo, but it give me empty results. I want something like "you are in Czech Republic, Prague, near the street Biskupcova". Maybe something similar your described in feature request #45

When I print found administrative regions in LocationService.cpp:1264 it gives me some description where this position is, but why this information is not returned from DescribeLocation function?

for (auto &adminRegion: adminRegionVisitor.adminRegions){
    AdminRegionRef regRef = adminRegion.second;
    std::cout << "admin region: " << regRef->name << std::endl;
}

Am I looking for wrong function?

While everybody can generate the doxygen documentation itself, it may be wise to place it onto the web page, too.

Currently a way label is centered between start and end of a way and drawn just once. This is normally OK, since most ways are normally not that long (nevertheless see issue #35).

For better labelling of longer ways - and similar to shields - a contour label should be drawn repeatedly with a configurable start offset and spacing between labels.

LocationService allows to describe a geo coordinate in relation to objects in the database.

In this case describe a coordinate in relation to a street and an address.

Example:
"20 meters north of BlaBlaBla Street 14."

libosmscout does a number of import validations resulting in warning and errors during import.

These warnings and errors often hint at mapping errors in the OSM data itself. It would be nice to allow evaluation of such information by the OSM mapper in form of HTML reports.

Some code infrastructure should be created that allows each import step to create/add to such HTML based error pages.

The error pages should allow easy further analysis by OSM mapper. For example objects should be directly link to the OSM pages for the same data.

Generating such reports may be a two step process. For example resolving libsosmcout object IDs to OSM ids may - if necessary - be a post processing step. Furth import steps may be offered just for the purpose of doing further quality analysis.

See topic

The class WorkQueue is defined in WorkQueue.h:

template<class R>
class WorkQueue
{

But it is used with non-class data types:

libosmscout-import\include\osmscout\import\Preprocess.h(78): WorkQueue<void> writeWorkerQueue;
libosmscout-map\include\osmscout\MapService.h(118): mutable WorkQueue<bool> nodeWorkerQueue;
libosmscout-map\include\osmscout\MapService.h(121): mutable WorkQueue<bool> wayWorkerQueue;
libosmscout-map\include\osmscout\MapService.h(124): mutable WorkQueue<bool> wayLowZoomWorkerQueue;
libosmscout-map\include\osmscout\MapService.h(127): mutable WorkQueue<bool> areaWorkerQueue;
libosmscout-map\include\osmscout\MapService.h(130): mutable WorkQueue<bool> areaLowZoomWorkerQueue;

This can create issues with strict compiler settings.

LocationService allows to describe a geo coordinate in relation to objects in the database.

In this case describe a coordinate in relation to a nearby street crossing.

Example:

"20m north Bla Street and Blub Street".

Currently Way types are set to typeIgnore during Preprocessing even if the type is only ignorable. That should be changed so that types are set to ignore after relation processing have been done.

This way relations will first have a proper type and if that type is ignoreable their type will be set to ignore afterwards.

Currently we report relation sas typeless in casees where the type is just ignoreable.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Implement a simple class wrapper for reading the distribution.dat file.

Allow symbols to be drawn with some offset from the actual line

Allow to render simple line patterns as area fill (two colors, pen thickness and direction can be configured).

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

I have built the latest git repository (9893440) and I have tried to Import the following file:
http://download.geofabrik.de/europe/hungary-140101.osm.pbf

With the following command:
./Import/Import --typefile stylesheets/map.ost --destinationDirectory hungary ~/Letöltések/osm/hungary-140101.osm.pbf

The backtrace:
` - Generate wayarea.tmp...
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

Program received signal SIGABRT, Aborted.
0x00007ffff6ee4c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: Nincs ilyen fájl vagy könyvtár.
(gdb) bt
#0 0x00007ffff6ee4c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff6ee8028 in __GI_abort () at abort.c:89
#2 0x00007ffff74e9535 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff74e76d6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff74e7703 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff74e7922 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007ffff74e7e0d in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7 0x00007ffff7838960 in allocate (this=, __n=282013081) at /usr/include/c++/4.8/ext/new_allocator.h:104
#8 _M_allocate (this=, __n=282013081) at /usr/include/c++/4.8/bits/stl_vector.h:168
#9 _M_allocate_and_copystd::move_iterator<std::shared_ptrosmscout::RawWay* > (this=, __last=..., __first=..., __n=282013081) at /usr/include/c++/4.8/bits/stl_vector.h:1138
#10 reserve (__n=282013081, this=0x7fffffffc680) at /usr/include/c++/4.8/bits/vector.tcc:75
#11 osmscout::WayAreaDataGenerator::Import (this=0x6122d8, typeConfig=std::shared_ptr (count 1, weak 0) 0x615478, parameter=..., progress=...)

at /home/mm/Projektek/jolla/libosmscout/libosmscout-import/src/osmscout/import/GenWayAreaDat.cpp:261

#12 0x00007ffff784579b in osmscout::Importer::ExecuteModules (this=this@entry=0x7fffffffd390, typeConfig=std::shared_ptr (count 1, weak 0) 0x615478, progress=...)

at /home/mm/Projektek/jolla/libosmscout/libosmscout-import/src/osmscout/import/Import.cpp:879

#13 0x00007ffff7846b05 in osmscout::Importer::Import (this=this@entry=0x7fffffffd390, progress=...) at /home/mm/Projektek/jolla/libosmscout/libosmscout-import/src/osmscout/import/Import.cpp:976
#14 0x0000000000405ee1 in main (argc=, argv=) at /home/mm/Projektek/jolla/libosmscout/Import/src/Import.cpp:813`

Let me know if I need to provide further information (build it with debug symbols, etc.)

Allow to define symbol dimensions in meter, so that actual rendering of the symbol is zoom level aware.

This may be helpful for rendering things like light circles around street lamp and similar.

Implement a simple class wrapper for reading the bounding.dat file.

Above combination currently fails, it looks like there is some Appveyor-specific problem with from time to time appears:

CMake Error at C:/msys64/mingw64/lib/cmake/Qt5Qml/Qt5Qml_QTcpServerConnectionFactory.cmake:2 (add_library):
  add_library cannot create imported target
  "Qt5::QTcpServerConnectionFactory" because another target with the same
  name already exists.
Call Stack (most recent call first):
  C:/msys64/mingw64/lib/cmake/Qt5Qml/Qt5QmlConfigExtras.cmake:4 (include)
  C:/msys64/mingw64/lib/cmake/Qt5Qml/Qt5QmlConfig.cmake:172 (include)
  cmake/features.cmake:110 (find_package)
  CMakeLists.txt:108 (include)

I'm not sure if this is something we have some influence on. Nevertheless a fix or work around would be more than helpful.

Write down as web site tutorial document: How I can do performance analysis and what are the tuning options to improve performance. See my various emails regarding that topicon the mailing list for principle content.

"I now have the rendered map" how do I render things on top of it?

Please add a description of the two alternatives as tutorial to the web site.

Allow configuration of spacing between symbols drawn

Currently the Travis build for libosmsocut in the combination gcc/cmake/Linux fails:

...
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.

Please set them or make sure they are set and tested correctly in the CMake files:

GLUT_Xi_LIBRARY (ADVANCED)

    linked by target "osmscout_map_opengl" in directory /home/travis/build/Framstag/libosmscout/libosmscout-map-opengl

PROTOBUF_PROTOC_LIBRARY (ADVANCED)

    linked by target "osmscout_import" in directory /home/travis/build/Framstag/libosmscout/libosmscout-import
...

Either some installation packages are missing or the cmake check is not correct (cmake should only fail on required dependencies missing, optional dependencies missing should never make the build fail).

I need someone with more cmake knowledge to help me.

We should rebuild the web page

• It should be more modular and better structured.
• The web page source should be checked in into git, so that other people can update the content, too.
• The web page should be updated from git using a build job
• The web page should be build using a static web page generator like Hugo or Jekyll.

Title says it all. We can now do some fancy formatting and could even inline some explanatory images, so let's move it to the web site.