Opened 7 years ago

Last modified 2 weeks ago

#754 new defect/bug

Multipolygon relations not handled correctly

Reported by: jrahe Owned by: KaZeR
Priority: major Milestone: version 0.5.2
Component: tools Version: git master
Severity: Keywords: multi, poly, water, coast
Cc: michael@…, http://wiki.navit-project.org/index.php/user:tegzed, cp15

Description

settlement (landuse=residential type=multipolygon) will not be displayed (colored) on the map.

example 1: http://www.openstreetmap.org/browse/relation/1304643[[BR]]

example 2: http://www.openstreetmap.org/browse/relation/1347636

Maybe similar problem like multipolygons for natural=water (http://trac.navit-project.org/ticket/689)


settlement (landuse=residential) are ok.

example 3: http://www.openstreetmap.org/browse/way/87861851[[BR]]

example 4: http://www.openstreetmap.org/browse/way/24961414


Greetings Jörg

Attachments (12)

water_relation.diff (10.2 KB) - added by tegzed 6 years ago.
fixed waterway="riverbank" tag support
area_relation.diff (17.1 KB) - added by tegzed 6 years ago.
added support for disjunct outer polygons
navit.png (50.4 KB) - added by fred jelk 6 years ago.
osm.png (124.5 KB) - added by fred jelk 6 years ago.
multipolygon.png (113.9 KB) - added by fred jelk 6 years ago.
00.png (103.3 KB) - added by tegzed 6 years ago.
16.png (146.8 KB) - added by tegzed 6 years ago.
isle_not_visible.png (95.8 KB) - added by fred jelk 6 years ago.
polygon_hole.diff (99.8 KB) - added by tegzed 6 years ago.
fixed intersection detection for horizontal and vertical lines
defect_multipolygon.osm (17.8 KB) - added by fred jelk 6 years ago.
for testing
Warnow_HRO Navit.png (168.8 KB) - added by usul 4 years ago.
Warnow_HRO OSM.jpg (120.4 KB) - added by usul 4 years ago.

Download all attachments as: .zip

Change History (126)

comment:1 Changed 7 years ago by jrahe

I forgot: navit 0.2.0 3708 WinCE map from Planet::Extractor 26.01.2011

comment:2 Changed 7 years ago by jrahe

FYI Same or similar issue with maps from OSM in mapfactor Navigator 10 free http://forum.openstreetmap.org/viewtopic.php?id=9839&p=4

Greetings Jörg

comment:3 Changed 7 years ago by jrahe

FYI issue in mapfactor Navigator 10 free seemed to be solved:

Berichtigt, danke. ...neuere Dateien ... sollten zur Verfügung nächste Woche sein.
danke
Martin

s.a. http://forum.mapfactor.com/discussion/12/de-problem-darstellung-landuseresidential-mit-typemultipolygon/#Item_4

(I wasn´t able yet to test it, because the next update will be next week)

Greetings Jörg

comment:4 Changed 7 years ago by jrahe

  • Priority changed from major to minor

Issue still exists in 0.2.0 4004 WinCE map from Planet::Extractor 25.02.2011


FYI: same issue in mapfactor Navigator is solved.

comment:5 Changed 7 years ago by korrosa

Hi jrahe - many thanks for keeping the ticket updated (and also for putting your custom menu on the wiki! Menu_configurations#QVGA_Square_.28240x240.29_Configuration_1_.28German.29 for those interested!)

As far as I know, Navit doesn't have full support for relations just yet (though they are recognised by maptool http://navit.svn.sourceforge.net/viewvc/navit/trunk/navit/navit/maptool/osm.c?view=markup) hence multipolygons are not yet supported. This is to the best of my knowledge, and by way of ensuring that you're aware that we're aware of the issue!

(If anyone knows different, please update this ticket!)

comment:6 Changed 7 years ago by jrahe

Hello korrosa, thanks for responding.

...its good to know that you know ;-)

Greetings Jörg

comment:7 Changed 6 years ago by mvglasow (2)

#689 describes the same issue with lakes. I'm also seeing it happen with highways which are areas (tags on relation: type=multipolygon; highway=pedestrian; name=Place Scheurer-Kestner).

Links:

Tested on Android (CyanogenMod? 7 on GeeksPhone? One), r4696, map data downloaded today from planet extractor.

This is most likely a design question: where would relation data be applied to geometries? In maptool? In the map driver? In navit core? (Does any of the latter two have any capabilities that could be used for handilng relations?)

If the binfile format allows for complex geometries, such as polygons with holes, then it should be possible to break down multipolygon relations in maptool. Multiple role=outer members can be converted into multiple polygons (each with the same tags) if not directly supported by the binfile format.

I'm closing #689 as a duplicate of this ticket and extending the scope of this one to generic handling of multipolygons.

Last edited 6 years ago by mvglasow (2) (previous) (diff)

comment:8 Changed 6 years ago by mvglasow (2)

  • Summary changed from Problem with multipolygon for landuse=residential to Multipolygon relations not handled correctly

comment:9 Changed 6 years ago by mvglasow (2)

  • Cc michael@… added

comment:10 Changed 6 years ago by tryagain

AFAIK Multipolygones are handled in maptool. They should be working for country borders now. Not sure if cp15 done extending that to anything else.

comment:11 Changed 6 years ago by zoff99

Priority: minor? i think you are underestimating that problem. already many rivers, lakes and some roads are disappearing in navit, because in OSM they have been converted to relations. --> (see danube in vienna, donau durch wien)

i fear that in a few months other features will become useless, when roads are missing. dont you thing so? this trend is progressing very fast

at least a workaround like user:mvglasow suggested should be applied ASAP!!

Multiple role=outer members can be converted into multiple polygons
(each with the same tags) if not directly supported by the binfile format.

comment:12 Changed 6 years ago by zoff99

  • Component changed from core to tools
  • Priority changed from minor to major

comment:13 Changed 6 years ago by fred jelk

this problem still exists (svn 4838).

the multipolygons won't be visible in navit - its really annoying, because a lot of the lakes, rivers, forests, residentials, buildings, parkings (and much more) are taggt as multipolygons, and so many things are invisible in Navit.

its really a big problem.

have a look at these 2 pictures (both times the same area - one is a screenshot from osm.org; the other is a screenshot from navit):

http://trac.navit-project.org/attachment/ticket/689/osm_with_lakes.png

http://trac.navit-project.org/attachment/ticket/689/navit_without_lakes.png

Last edited 6 years ago by fred jelk (previous) (diff)

comment:14 Changed 6 years ago by tegzed

Hello,

I created a patch for maptool to handle multipolygons (see attached water_relation.diff). Currently it is in early pre-experimental :) state and handles only natural="water" multipolygons. Running this version of maptool I experienced other problems (which appeared for me before the modification also). I think it is related to self intersecting coastlines, but I'm not sure. Maybe the algorithm that breaks coastlines into tiles needs some improvement. Please test the patch and let me know how it works for you.

David Tegze

comment:15 Changed 6 years ago by tegzed

Latest update to the patch solves some issues of the previous version. Now it filters out self-intersecting multipolygons, and only outer polygons are used. I tested the patch with osm data of Hungary and Austria and the non-self-intersecting multipolygons I tested were OK. If I get positive feedbacks I will commit it after some cleanup.

comment:16 Changed 6 years ago by tegzed

I have updated the patch again. When applied, maptool skips self-intersecting water areas not only for multipolygons but for ordinary polygons, too. This avoids flooding effects I experienced by the osm data of certain countries (Germany and Romania and maybe some others also).

Changed 6 years ago by tegzed

fixed waterway="riverbank" tag support

comment:17 Changed 6 years ago by fred jelk

@tegzed... looks great and works fine for my maps. thanks for this patch. I hope, there will be a patch available for the other MP-areas soon. And I hope also, it will be integrate in the original source code.

comment:18 Changed 6 years ago by korrosa

tegzed: Ignore what I previously told you on IRC - the patch works fine for me too!

comment:19 Changed 6 years ago by tegzed

Hi korrosa, hi wakefred,

Thanks for your feedback, I'll implement the handling of other MP areas when I can find the time for that. Hopefully in a couple of days. Next version will map osm tags to navit item types using the same mechanism that is used for non-MP items today.

comment:20 Changed 6 years ago by tegzed

Hello,

I updated the patch again(see area_relation.diff), now all area typed items are generated based on the relation tags that would be generated for a normal way with the same tags. This version also emits warnings about self intersecting polygons during way and relation processing, so the user have some info about the skipped items (self-intersecting polygons introduce nasty flooding effect in navit). Unfortunately currently navit's map drivers cannot handle polygons with holes, so inner members are not processed. After some testing the patch seems to generate most of the items that were missing before.

comment:21 Changed 6 years ago by fred jelk

@tegzed... now, with this new patch (area_relation.diff), the multipolygon-lakes are not visible in navit.

comment:22 Changed 6 years ago by tegzed

Hi wakefred,

Can you pls link a non-visible lake? Maybe it is self-intersecting (you will see a line something like this for the problemmatic relation in the maptool output: OSM Warning:http://www.openstreetmap.org/browse/relation/1691138 Self intersecting relation area ) or no rule matches the tags of the lake.

comment:23 Changed 6 years ago by fred jelk

p.e. http://www.openstreetmap.org/browse/relation/1537206 with the patch water_relation.diff this lake is visible in navit, but not with the area_relation.diff

comment:24 Changed 6 years ago by tegzed

Thanks for the link, the problem was related to handling the rule matching after mapping osm tags to navit type. When we had more that one matches, only one item is generated from the first match. Now we generate an item for each match. Please let me know your results with the updated patch.

comment:25 Changed 6 years ago by fred jelk

@tegzed... thanks a lot... now, it work's perfect for me.

Changed 6 years ago by tegzed

added support for disjunct outer polygons

comment:26 Changed 6 years ago by tegzed

Hello,

I updated the patch again, this version supports disjunct outer polygons. If you can test it, please give me some feedback about the results.

comment:27 Changed 6 years ago by fred jelk

@tegzed... works like a charm...

Changed 6 years ago by fred jelk

Changed 6 years ago by fred jelk

comment:28 Changed 6 years ago by fred jelk

@tegzed... now, it would be great, if the islets will be also rendered. p.e. the ways 125314597 and 125319223 in the relation 1282756. link: http://www.openstreetmap.org/?lat=46.69811&lon=7.1009&zoom=17&layers=M see also the screenshots: in navit, the islet isn't visible ( http://trac.navit-project.org/attachment/ticket/754/navit.png ). in mapnik is the islet visible ( http://trac.navit-project.org/attachment/ticket/754/osm.png ).

Last edited 6 years ago by fred jelk (previous) (diff)

comment:29 Changed 6 years ago by tegzed

Hello wakefred,

Unfortunately supporting polygons with holes is not so easy, since current map file formats cannot represent these polygons and map drivers and graphics drivers in navit do not support polygons of this type. After the representation problem is solved in the map file formats, we need a good tessellation routine to cut these polygons into several polygons without holes, but this is also not very easy. I think the solution should be discussed with Cp15. The most correct solution would be to redesign the mentioned parts which would be a huge work...

Changed 6 years ago by fred jelk

comment:30 Changed 6 years ago by fred jelk

@tegzed... I'm not sure, if I understand it correctly... But, if you have a look at the attached screenshot "multipolygon.png" ( http://trac.navit-project.org/attachment/ticket/754/multipolygon.png ), you can see, for other multipolygons, it works... p.e. at this MP id=1713904, the islets are visible, which are tagged as natural=scrub.

Last edited 6 years ago by fred jelk (previous) (diff)

comment:31 Changed 6 years ago by tegzed

I think in your last example not only the <relation> but the <way> elements of the islands are tagged so that separate items are generated for them. These items are rendered above the item that is generated from the relation. Maybe in the case above where inslets are not rendered, the <way> tags are not tagged,so only the relation is rendered - without hole. The problem is that the existing item structure in navit cannot be extended to contain info about inner polygons in a way it remains compatible with the existing code.

comment:32 Changed 6 years ago by fred jelk

all right. thanks for the answer. but i have another islet: per excample the way with the id=125314599. this islet have the tag natural=wood directly on the way. but in navit its not rendered. here is a direct link to the islet: http://www.openstreetmap.org/?lat=46.68156&lon=7.0957&zoom=17&layers=M you see, its the same scheme like http://trac.navit-project.org/attachment/ticket/754/multipolygon.png where the islets will be rendered (at these islets here its just missing the tag place=islet and they are tagged as natural=scrub instead of natural=wood)

comment:33 Changed 6 years ago by tegzed

Maybe in this case the water is rendered after the island and you will not see the island. As I remember render order is specified by the order of itemgra entries in navit.xml. Anyway I thought about the problem and maybe there is a solution. Maybe the info about inner polygons can be stored as an attribute of the map item and the polygon rendering routine should be modified to render polygons with such an attribute using a special method that can handle polygons with holes. In this way we can avoid modifying the map format and the related large amount of code in maptool and binfile/textfile map driver. I will try to implement this and attach a patch when I have some time for that.

comment:34 Changed 6 years ago by fred jelk

that would be great, if you can implement this. thanks a lot for your effort.

comment:35 Changed 6 years ago by tegzed

Hello again,

I attached an initial version of relation area handling with hole support. I introduced a new attribute type to hold the info about the inner members of the relations. Both maptool and navit is updated. This modification stores inner polygon info into an attribute of the generated map items. Navit uses this info to triangulate these items so that the holes are preserved. The triangulation algorithm is borrowed from here: http://www.cs.unc.edu/~dm/CODE/GEM/chapter.html and modified to fit navit. The source code for the triangulator is from ftp://ftp.cs.unc.edu/pub/users/manocha/CODE/Triangulation/triangulation.tar.gz . Maybe I will change the design to do the triangulation in maptool and store the info about the triangles in an attribute if it turns out that the trianagulation takes too much cpu cycles runtime. However this will result in bigger map files. The code is not yet complete, it needs a lot of clean up and arrangement and there may be cases where the triangulator will not work, but I experienced that it works well for most non-intersecting polygons. Intersecting polygons are filtered out since the triangulator cannot handle them. If you try this please let me know your experiences.

comment:36 Changed 6 years ago by tegzed

  • Cc http://wiki.navit-project.org/index.php/user:tegzed added

comment:37 Changed 6 years ago by tegzed

Hi,

In the latest diff I moved triangulation of polygons with holes to maptool to improve runtime performance of navit. Please test it and let me know your results.

Dandor

comment:38 Changed 6 years ago by fred jelk

hi tegzed, this patch don't work... I would create a map from Switzerland and I get this message in the terminal:

...
navit:attr_data_size:size for (null) unknown
navit:attr_data_size:size for (null) unknown
navit:attr_data_size:size for (null) unknown
OSM Warning:http://www.openstreetmap.org/browse/relation/16239 Broken country polygon 'AT'
navit:attr_data_size:size for (null) unknown
OSM Warning:http://www.openstreetmap.org/browse/relation/51477 Broken country polygon 'de'
navit:attr_data_size:size for (null) unknown
navit:attr_data_size:size for (null) unknown
navit:attr_data_size:size for (null) unknown
navit:attr_data_size:size for (null) unknown
navit:attr_data_size:size for (null) unknown
navit:attr_data_size:size for (null) unknown
navit:attr_data_size:size for (null) unknown
Speicherzugriffsfehler

After the message "Speicherzugriffsfehler" it stops.

I've installed the svn-4936 and the new patch polygon_hole.diff (on a Ubuntu 11.10). On my Ubuntu the old patch area_relation.diff with svn-4854 work's perfekt.

comment:39 Changed 6 years ago by tegzed

Hi wakefred,

Thanks for your feedbacks again. I uploaded another version which should behave better in cases where the previous one crashed. Please try it and let me know if this fixes the problems on your side too.

comment:40 Changed 6 years ago by fred jelk

Hi tegzed,

I've tested this Patch again. This time without the error as above. But the holes in the Multipolygons are still not visible (p.e. http://www.openstreetmap.org/?lat=46.68156&lon=7.0957&zoom=17&layers=M ). And with this patch, there are also a lot of Multipolygons (without holes) not visible (p.e. the MP with landuse=residential in my village http://www.openstreetmap.org/?lat=46.74153&lon=7.28581&zoom=16&layers=M ). The old patch area_relation.diff with svn-4854 show's these landuses correctly.

Changed 6 years ago by tegzed

comment:41 Changed 6 years ago by tegzed

Hmm, is the patch succeeded for you? For me these polygons seem to be ok(see the attached screenshots).

Changed 6 years ago by tegzed

comment:42 Changed 6 years ago by tegzed

Wakefred,

Try removing first the new files that this patch should create: tri.c interface.h triangulate.h misc_.c monotone.c construct.c. Patch appends the content of these files instead of overwriting them, which can cause problems. For me your examples work correctly.

comment:43 Changed 6 years ago by tegzed

It seems that for small map extracts this works correctly,but for whole countries it does not. I will try to fix this.

comment:44 Changed 6 years ago by fred jelk

I would test it today again. But thank's for the reason it wouldn't work: i've tested it with the whole Switzerland.

comment:45 Changed 6 years ago by tegzed

Wakefred, Can you test the latest version?

Changed 6 years ago by fred jelk

comment:46 Changed 6 years ago by fred jelk

Hi tegzed, the normal MPs are o.k., but the holes within the MPs are still not visible. see attached screenshot (isle_not_visible.png) from this isle: http://www.openstreetmap.org/?lat=46.68156&lon=7.0957&zoom=17&layers=M I made a map of Switzerland. With the patch "area_relation.diff" and svn-4854, the map of Switzerland was 67,1 MB big. With the new patch the map of Switzerland have a size of 80,5 MB.

comment:47 Changed 6 years ago by tegzed

Do you use the recompiled navit or the original one? Maptool triangulates polygons that have holes and adds the triangle info into a new map item attribute type which will increases the map size. So I guess your maps are correct. But you need to use the patched version of navit on your device since older versions cannot interpret triangle info. Non-patched navit versions will only display the outer polygons without holes since outer info can be put into the original map format also. So please use the patched navit version to see the MPs with holes.

comment:48 Changed 6 years ago by fred jelk

Hi tegzed, it was my misstake. I didn't installed a patched version on my android-device. but now, i checked it with the patched navit-version on my notebook: great... wow, this works perfekt. good job... Now it would be great, if this patch could be implemented into the source code of navit, so that everybody can profit from this patch and the new maps.

comment:49 Changed 6 years ago by fred jelk

After some tests, I've found no problems with this patch. Its great. Now, it would also be nice, if you can expand this patch for the inners from buildings.

comment:50 Changed 6 years ago by tegzed

Buildings should also be supported by the patch. However if both the <way>s and <relation>s that uses that way as outer in your osm file are tagged so that map items (eg building) need to be generated then at the end of generation process you will have one item for the <way> without hole and one item for the <relation> with holes. These polygons will be drawn over each other and at the end it will look like as a polygon without hole.

<way id="1111">
<tag building="xxx">   //hole-less item will be generated
</way>
...
<relation id="xxxx">
<member type="way" ref="1111" role="outer"/>
<tag building="xxx">   //with-hole item will be generated
</relation>

It is not so easy to handle these situations (for example by removing hole-less items where we have relation based item) since one way can be included from several relations etc...

Try removing the <tag building="xxx"> tags from the <way> tag (and leaving it there in the relation) in your osm file. If you see the holes after generating map from this osm file, then you have the above problem.

comment:51 Changed 6 years ago by fred jelk

yes, I saw it: the holes in the buildings are visible in Navit with this patch - if the outer-way haven't the tag "building=yes". this is o.k. like this. thanks for your feedback.

comment:52 Changed 6 years ago by fred jelk

@tegzed... I have a little problem: I can't compile it for android, because I get an error while compiling:

/home/wakefred/navit/svn/navit_repository/navit/navit/misc_.c:136: undefined reference to `log2'
.libs/misc_.o: In function `math_N':
/home/wakefred/navit/svn/navit_repository/navit/navit/misc_.c:150: undefined reference to `log2'

what can I do? Do you have an idea? (the patch "polygon_hole.diff" is correct implemented)

Last edited 6 years ago by fred jelk (previous) (diff)

comment:53 Changed 6 years ago by tegzed

The latest version that is not yet attached moves all triangulation code to maptool from libnavit, so navit does not depend on the triangulation code which contains the call to log2. This should fix the build on android. Maybe your ARM version of libmath does not contain the log2 function. I will update the patch soon.

comment:54 Changed 6 years ago by tegzed

Wakefred, The newest one should compile on android, too.

comment:55 Changed 6 years ago by fred jelk

hi tegzed... thanks a lot, but there are two bugs with this newest patch:

  1. Multipolygon-Areas (p.e. residential) aren't visible (tested on a Ubuntu-Notebook with installed actual patch) - with this patch, the map of Switzerland will be just 66,3 MB big, instead of the 80,5 MB like the old polygon_hole-Patch)
  2. building an apk is possible, but on the Galaxy Nexus (ICS 4.0.3 - CM9 - newest franco.kernel) it crash at the start (don't know, if it crashs on other android-devices) : installation works, but if I would start Navit, it close immediatly.

My installation: navit-4936 with new polygon_hole.diff -> the installation of the new polygon_hole.diff don't work proper: the attr.c is to new. first I must get an older attr.c (4923 - because 4922 is no more available). After this changing, the patch can be installed.

Last edited 6 years ago by fred jelk (previous) (diff)

comment:56 Changed 6 years ago by tegzed

The problem is that the patch is created against an older svn version not the current. attr.c contains an important part of the change, simply using an older one is not ok. This explains both the lack of(or incorrect) triangle data in your map and the crash. I need to create a patch against current svn.

comment:57 Changed 6 years ago by tegzed

wakefred, I updated the patch. now it is created against 4971.

comment:58 follow-up: Changed 6 years ago by fred jelk

@tegzed... thanks a lot for this new patch:

  1. the maps looks great with this patch: MPs with holes and also MPs without holes will be shown correct. I've found no problems - on a linux-computer with a patched navit, it works.
  2. creating an apk for my android device don't work with this patch. Creating an apk without patch works, but with this patch, I get this error:
-resource-src:
     [echo] Generating R.java / Manifest.java from the resources...
     [aapt] /home/wakefred/navit/work/build/navit/android/AndroidManifest.xml:2: error: No resource identifier found for attribute 'installLocation' in package 'android'

BUILD FAILED
/home/wakefred/navit/android-sdk-linux_x86/tools/ant/main_rules.xml:310: null returned: 1

comment:59 in reply to: ↑ 58 Changed 6 years ago by tegzed

For me this problem seems to be unrelated. The patch does not touch any android specific code. Try removing the installLocation entry from the manifest(in my AndroidManifest?.xml file there is no installLocation entry) file or check your android API version you compile against. If I remember well navit should be compiled against 1.6.

Update: check http://irclogs.navit.ie/%23navit-2011-08-24.log Here Rikky says in his commit log: Target API has to be 8 if installLocation is specified. Maybe this helps

Last edited 6 years ago by tegzed (previous) (diff)

comment:60 Changed 6 years ago by fred jelk

all right. with Target API 8 the apk can be build. it wasn't a problem of the patch. it is possible to implement this patch to the source code, so everyone can create maps with MP-support and so they can see also the MP-holes?

comment:61 follow-up: Changed 6 years ago by fred jelk

For a special area, I have a problem to create a bin-map: its for Benelux. I get an error like "Speicherzugriffsfehler" from maptool. I have this problem from the pbf of an extract from europe.osm.pbf (geofabrik) and also, if I take the pbf from http://planet.openstreetmap.nl/benelux/. Its just with the new patch. With the old patch (area_relation.diff), I've had never this problem. I've created some maps with the new patch. If someone would like to test them, you can find some countries (AT, CH, DE, LI and DACH) on http://dl.artpc.ch/navit/maps/ (Benelux can't be created because of the error)

comment:62 in reply to: ↑ 61 Changed 6 years ago by korrosa

Replying to wakefred:

I've created some maps with the new patch. If someone would like to test them, you can find some countries (AT, CH, DE, LI and DACH) on http://dl.artpc.ch/navit/maps/ (Benelux can't be created because of the error)

Fancy doing a GB one too? I'll gladly test that one on an Android device.(http://download.geofabrik.de/osm/europe/great_britain.osm.pbf)

comment:63 Changed 6 years ago by fred jelk

@korrosa... I'll do it tomorrow morning.

comment:64 Changed 6 years ago by tegzed

Hi Wakefred, thanks for the report, I will try to find the time to fix it in a couple of days.

Dandor

comment:65 Changed 6 years ago by fred jelk

@korrosa and tegzed... I'm sorry, but for Great-Britain, I have the same error like Benelux: "Speicherzugriffsfehler" (Translation: Memory Access Error)

comment:66 Changed 6 years ago by fred jelk

this new Patch works now also for Great-Britain and Benelux. I think, maptool is a little slower now than bevor, but it works. navitmap-GB.bin is now online on http://dl.artpc.ch/navit/maps/ and navitmap-benelux.bin will be online in 30 minutes. the other maps (AT, DE, CH, LI) will be created after benelux with this new patch.

comment:67 Changed 6 years ago by tegzed

Yep, now this can process the mentioned maps, however I noticed that there are some polygons that were filtered out by this version needlessly. I hope to fix these problems also. Please let me know if you find crashes or other problems. When the code works as expected I will need to do some clean up and review. If you have an osm planet file and some processing capacity you may help me to process the full osm data also. The inceased runtime is caused by additional checks for self-intersecting polygons.

comment:68 Changed 6 years ago by korrosa

I can confirm that the GB map works fine for me on Android for viewing and searching - I'll test the routing on it tonight, but I don't expect any problems. Good work guys!

comment:69 Changed 6 years ago by fred jelk

I made a changement from Great Britain to British Isles. Now, there will be the map "navitmap-british_isles.bin" for Great-Britain, Ireland and Northern Ireland. And this map will also be created 2-3 times a week (like AT, CH, DE, LI).

comment:70 follow-up: Changed 6 years ago by fred jelk

I found a "small bug": when a multipolygon-lake have the attributes natural=water and landuse=basin, this area will not be visible with the new patch (with the patch area_relations.diff these lakes were visible).

Last edited 6 years ago by fred jelk (previous) (diff)

comment:71 Changed 6 years ago by fred jelk

@tegzed... I've just started to download the planet and create a navitmap-planet.bin now. So it can work over night.

comment:72 in reply to: ↑ 70 Changed 6 years ago by tegzed

Replying to wakefred:

Maybe this isn't caused by tagging, but it can be the bug I write in http://trac.navit-project.org/ticket/754#comment:67 . Can you link this lake pls?

comment:73 follow-up: Changed 6 years ago by fred jelk

its this lake: http://www.openstreetmap.org/browse/relation/1537206 (but 2 hours ago, I deleted the attribute "landuse=basin" in this relation. Now it will be visible in navit also)

comment:74 follow-up: Changed 6 years ago by rico

Hi,

with this patch navit does'nt show any multipolygons for me, e.g. forests. Areas, that are not MPs are ok. It doesn't work neither with gtk nor with internal+qt. Do I have to modify layouts in navit.xml?

comment:75 in reply to: ↑ 74 ; follow-up: Changed 6 years ago by tegzed

Replying to rico: Rico, you need to generate your maps with the patched maptool and use patched navit to display these maps.

comment:76 in reply to: ↑ 73 Changed 6 years ago by tegzed

Replying to wakefred: Wakefred, I did some investigation and it turned out that this landuse=basin tag problem was a bug in the rule match handling. I updated the patch with the fix.

comment:77 follow-up: Changed 6 years ago by fred jelk

@tegzed...
1. The bug "landuse=basin" is fixed. it works now. I'll create new maps today.
2. The planet.bin wasn't created because of a problem of my PC: the size of my VM, where I create the maps, was to small. I will try it this night again with a bigger VM.

comment:78 in reply to: ↑ 77 Changed 6 years ago by tegzed

Replying to wakefred: All right, thanks for your feedback and your efforts to test planet map generation.

comment:79 in reply to: ↑ 75 ; follow-up: Changed 6 years ago by rico

Replying to http://wiki.navit-project.org/index.php/user:tegzed:

I used a patched navit and a patched maptool to generate maps. wakefreds maps also don't work.

comment:80 in reply to: ↑ 79 Changed 6 years ago by korrosa

Replying to rico:

I used a patched navit and a patched maptool to generate maps. wakefreds maps also don't work.

rico: What device are you using, and is your navit.xml modified in any way?

comment:81 follow-up: Changed 6 years ago by fred jelk

@rico... which map is not working? have you an ID of the Multipolygon, which is not working?

comment:82 in reply to: ↑ 81 Changed 6 years ago by rico

@tegzed: I'm using a Debian Desktop and tested with a unmodified navit.xml too - no luck.

@wakefred: Germany is not working, for example http://www.openstreetmap.org/browse/relation/77659

comment:83 follow-up: Changed 6 years ago by fred jelk

@rico... All right. It isn't a problem of my maps or of the patch. The Problem is, that the tag "landuse=forest" isn't in the Relation. This tag is taggt wrongly direct on the outer-way instead in the relation. This isn't correct and should be changed. And the lakes in the south of this forest should also be integrated in the relation with the role=inner - till now, there are a lot of lakes not in the relation...
@tegzed... maybe you can change the code of this patch, so if there are such other wrong taggings (landuse-tag directly on the outer-way instead in the relation)?

Last edited 6 years ago by fred jelk (previous) (diff)

comment:84 in reply to: ↑ 83 Changed 6 years ago by rico

Replying to wakefred: Thanks, I didn't notice it. It means, all MPs in this area are defect. I will change it in osm as soon as possible.

Rico

comment:85 Changed 6 years ago by fred jelk

@tegzed... ufff... maptool is still at work for the planet - since yesterday at 16:00 h. I hope, this time, the space of the VM is big enough: the tmp-files needs really a lot of space for the whole planet.

comment:86 Changed 6 years ago by rdzidlic

polygon_hole.diff is against 4971 which is a bit unlucky because that snapshot is not in the snapshots repository (http://download.navit-project.org/navit/src/svn/). It does not apply cleanly to 4977 or 4979. Does it work cleanly with any other snapshots that are downloadable as tarballs?

comment:87 follow-up: Changed 6 years ago by fred jelk

@rdzidlic... I've tested this patch also with svn-4972: there it works cleanly (the maptool/CMakeLists.txt can be skipped, because it isn't necessary there).

Last edited 6 years ago by fred jelk (previous) (diff)

comment:88 in reply to: ↑ 87 Changed 6 years ago by rdzidlic

Replying to wakefred:

@rdzidlic... I've tested this patch also with svn-4972: there it works cleanly (the maptool/CMakeLists.txt can be skipped, because it isn't necessary there).

what am I doing wrong? Is some other patch needed or something else?

$ tar xvzf ../SOURCES/navit-svn-4972.tar.gz
$ cd navit-0.5.0/
$ patch -p0 --dry-run <../../SOURCES/polygon_hole.diff
patching file maptool/osm.c
Hunk #1 FAILED at 670.
Hunk #2 FAILED at 707.
Hunk #3 FAILED at 940.
Hunk #4 FAILED at 1480.
Hunk #5 FAILED at 1551.
Hunk #6 FAILED at 2560.
Hunk #7 FAILED at 2575.
Hunk #8 FAILED at 2590.
8 out of 8 hunks FAILED -- saving rejects to file maptool/osm.c.rej
patching file maptool/maptool.c
Hunk #1 FAILED at 745.
1 out of 1 hunk FAILED -- saving rejects to file maptool/maptool.c.
patching file maptool/maptool.h
Hunk #1 FAILED at 121.
Hunk #2 FAILED at 187.
Hunk #3 FAILED at 240.
3 out of 3 hunks FAILED -- saving rejects to file maptool/maptool.h
patching file maptool/itembin_buffer.c
Hunk #1 FAILED at 24.
1 out of 1 hunk FAILED -- saving rejects to file maptool/itembin_bu
patching file maptool/seidel/tri.c
patching file maptool/seidel/monotone.c
patching file maptool/seidel/misc_seidel.c
patching file maptool/seidel/construct.c
patching file maptool/seidel/triangulate.h
patching file maptool/seidel/interface.h
patching file maptool/geom.c
Hunk #1 FAILED at 19.
Hunk #2 FAILED at 357.
Hunk #3 FAILED at 620.
3 out of 3 hunks FAILED -- saving rejects to file maptool/geom.c.re
patching file maptool/Makefile.am
Hunk #1 FAILED at 5.
1 out of 1 hunk FAILED -- saving rejects to file maptool/Makefile.a
patching file maptool/boundaries.c
Hunk #1 FAILED at 19.
Hunk #2 FAILED at 70.
Hunk #3 FAILED at 192.
Hunk #4 FAILED at 228.
Hunk #5 FAILED at 246.
5 out of 5 hunks FAILED -- saving rejects to file maptool/boundarie
patching file maptool/CMakeLists.txt
Hunk #1 FAILED at 2.
1 out of 1 hunk FAILED -- saving rejects to file maptool/CMakeLists
patching file attr_def.h
Hunk #1 FAILED at 429.
1 out of 1 hunk FAILED -- saving rejects to file attr_def.h.rej
patching file attr.c
Hunk #1 FAILED at 492.
1 out of 1 hunk FAILED -- saving rejects to file attr.c.rej
patching file graphics.c
Hunk #1 FAILED at 50.
Hunk #2 FAILED at 402.
Hunk #3 FAILED at 452.
Hunk #4 FAILED at 860.
Hunk #5 FAILED at 876.
Hunk #6 FAILED at 889.
Hunk #7 FAILED at 910.
Hunk #8 FAILED at 1727.
Hunk #9 FAILED at 1741.
Hunk #10 FAILED at 2089.
Hunk #11 FAILED at 2110.
Hunk #12 FAILED at 2128.
12 out of 12 hunks FAILED -- saving rejects to file graphics.c.rej

comment:89 Changed 6 years ago by fred jelk

@rdzidlic... your pc don't patch the subfolders... Ubuntu have in some cases this problem. I have uploaded a patched svn-version, if you like: http://dl.artpc.ch/navit/navit-svn/navit-svn-4972_with_polygonhole_patch.tar.gz

comment:90 Changed 6 years ago by fred jelk

@tegzed... maptool is still at work for the planet. But I have the attached message in the terminal, but the CPU is still on 100% and the ways_split_.tmp is actualised 3 minutes ago. so I think, maptool is still normal at working.

...
OSM Warning:http://www.openstreetmap.org/browse/relation/307573 Broken country polygon 'pk'
OSM Warning:http://www.openstreetmap.org/browse/relation/536807 Broken country polygon 'lk'
add_segment: error
newtrap: Trapezoid-table overflow
newnode: Query-table overflow
newnode: Query-table overflow
newtrap: Trapezoid-table overflow
newnode: Query-table overflow
newnode: Query-table overflow
... (about 20 lines with newnode or newtrap)
newtrap: Trapezoid-table overflow
newnode: Query-table overflow
newnode: Query-table overflow
newtrap: Trapezoid-table overflow
newnode: Query-table overflow
newnode: Query-table overflow
newtrap: Trapezoid-table overflow
add_segment: error

comment:91 Changed 6 years ago by tegzed

It seems that this error is caused by huge polygons. These polygons will be filtered out and hopefully will cause fatal errors.

comment:92 Changed 6 years ago by fred jelk

@tegzed... the planet don't work. maptool aborted after 60 hours of work with the following message:

./navitmap-planet: Zeile 8: 12145 Speicherzugriffsfehler  maptool --protobuf -i planet-latest.osm.pbf navitmap-planet.bin

comment:93 Changed 6 years ago by tegzed

@wakefred Thanks for testing, I will implement some fix for the above errors which will hopefully solve the problem.

comment:94 Changed 6 years ago by rdzidlic

@wakefred: thanks for the tips, got latest patch, run autoreconf, tweaked a little bit and it compiles.

However I still can not see this lake: http://www.openstreetmap.org/?lat=48.39796&lon=11.60715&zoom=17&layers=M

wget -c --proxy=off "http://api.openstreetmap.org/api/0.6/map?bbox=11.60349,48.39469,11.61081,48.40123"
maptool kranzberg.bin  <map\?bbox\=11.60349\,48.39469\,11.61081\,48.40123 

regarding the "Speicherzugriffsfehler" when you were building the whole planet - is it possible that maptool run out of memory?

comment:95 Changed 6 years ago by fred jelk

@rdzidlic... you can't see this lake, because there is no multipolygon. maptool is rendering the landuse=scrub over the natural=water. there should be a multipolygon with the landuse=scrub as outer and the natural=water as inner. then it will be visible (the same with the little lake on the left side of this lake: tag it as MP; the lake as inner and the meadow as outer).

@all... friday night till saturday at 10:15 am my domain dl.artpc.ch wasn't available. But now, its available again and you can download the maps again.

Last edited 6 years ago by fred jelk (previous) (diff)

comment:96 Changed 6 years ago by fred jelk

All right... I make today over the day new maps for AT, CH, DE, LI, DACH, Benelux and British Isles. And at 16:00 h, I'll start the planet, again.

Last edited 6 years ago by fred jelk (previous) (diff)

comment:97 Changed 6 years ago by fred jelk

@all... Switzerland looks good. I hope, there will be other people to check other countries.
@tegzed... just for information: maptool is now much slower with this new patch, than with the polygon_hole.diff from last week (I think, maptool needs about 15% more time than last week).

comment:98 Changed 6 years ago by korrosa

New British Isles works fine for me...

comment:99 Changed 6 years ago by fred jelk

@tegzed... the planet don't work. maptool aborted after ~12 hours with a "Speicherzugriffsfehler". see the last ~50 lines:

OSM Warning:http://www.openstreetmap.org/browse/relation/1987925 Unknown role axis in member http://www.openstreetmap.org/browse/way/147221667 
OSM Warning:http://www.openstreetmap.org/browse/relation/1993208 Country Boundary doesn't contain an ISO3166-1 tag
OSM Warning:http://www.openstreetmap.org/browse/relation/1993867 Country Boundary doesn't contain an ISO3166-1 tag
OSM Warning:http://www.openstreetmap.org/browse/relation/1996871 Unknown role admin_centre in member http://www.openstreetmap.org/browse/way/56467378 
OSM Warning:http://www.openstreetmap.org/browse/relation/2019026 Unknown role yes in member http://www.openstreetmap.org/browse/way/149792189 
OSM Warning:http://www.openstreetmap.org/browse/relation/2019250 Unknown role yes in member http://www.openstreetmap.org/browse/way/149818946 
OSM Warning:http://www.openstreetmap.org/browse/relation/2032957 Unknown role  inner in member http://www.openstreetmap.org/browse/way/150852366 
OSM Warning:http://www.openstreetmap.org/browse/relation/2032957 Unknown role  inner in member http://www.openstreetmap.org/browse/way/150852384 
OSM Warning:http://www.openstreetmap.org/browse/relation/2032957 Unknown role  inner in member http://www.openstreetmap.org/browse/way/150852322 
OSM Warning:http://www.openstreetmap.org/browse/relation/2032957 Unknown role  inner in member http://www.openstreetmap.org/browse/way/150852314 
OSM Warning:http://www.openstreetmap.org/browse/relation/2032957 Unknown role  inner in member http://www.openstreetmap.org/browse/way/150852306 
OSM Warning:http://www.openstreetmap.org/browse/relation/2032957 Unknown role  inner in member http://www.openstreetmap.org/browse/way/150852302 
OSM Warning:http://www.openstreetmap.org/browse/relation/2032957 Unknown role  inner in member http://www.openstreetmap.org/browse/way/150852361 
OSM Warning:http://www.openstreetmap.org/browse/relation/2032957 Unknown role  inner in member http://www.openstreetmap.org/browse/way/150852297 
OSM Warning:http://www.openstreetmap.org/browse/relation/2032957 Unknown role  inner in member http://www.openstreetmap.org/browse/way/150852330 
OSM Warning:http://www.openstreetmap.org/browse/relation/2032957 Unknown role  inner in member http://www.openstreetmap.org/browse/way/150852392 
OSM Warning:http://www.openstreetmap.org/browse/relation/2032957 Unknown role  inner in member http://www.openstreetmap.org/browse/way/150852398 
OSM Warning:http://www.openstreetmap.org/browse/relation/2032957 Unknown role  inner in member http://www.openstreetmap.org/browse/way/150852337 
OSM Warning:http://www.openstreetmap.org/browse/relation/2032957 Unknown role  inner in member http://www.openstreetmap.org/browse/way/150852342 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role  outer in member http://www.openstreetmap.org/browse/way/151060298 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role  outer in member http://www.openstreetmap.org/browse/way/151060260 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role  outer in member http://www.openstreetmap.org/browse/way/151060261 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role  outer in member http://www.openstreetmap.org/browse/way/151060281 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role  outer in member http://www.openstreetmap.org/browse/way/151060263 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role  outer in member http://www.openstreetmap.org/browse/way/151060262 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role  outer in member http://www.openstreetmap.org/browse/way/151060266 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role  outer in member http://www.openstreetmap.org/browse/way/151060269 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role  outer in member http://www.openstreetmap.org/browse/way/151060271 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role  outer in member http://www.openstreetmap.org/browse/way/151060272 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role  inner in member http://www.openstreetmap.org/browse/way/151060273 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role   outer in member http://www.openstreetmap.org/browse/way/151060302 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role   outer in member http://www.openstreetmap.org/browse/way/151060306 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role   outer in member http://www.openstreetmap.org/browse/way/151060308 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role   outer in member http://www.openstreetmap.org/browse/way/151060315 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role   outer in member http://www.openstreetmap.org/browse/way/151060318 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role   outer in member http://www.openstreetmap.org/browse/way/151060319 
OSM Warning:http://www.openstreetmap.org/browse/relation/2035909 Unknown role   outer in member http://www.openstreetmap.org/browse/way/151060261 
OSM Warning:http://www.openstreetmap.org/browse/relation/2036496 Unknown role  outer in member http://www.openstreetmap.org/browse/way/151093058 
OSM Warning:http://www.openstreetmap.org/browse/relation/2036496 Unknown role  outer in member http://www.openstreetmap.org/browse/way/151093060 
OSM Warning:http://www.openstreetmap.org/browse/relation/2036496 Unknown role  outer in member http://www.openstreetmap.org/browse/way/151093061 
OSM Warning:http://www.openstreetmap.org/browse/relation/2036496 Unknown role  outer in member http://www.openstreetmap.org/browse/way/151093062 
OSM Warning:http://www.openstreetmap.org/browse/relation/2036496 Unknown role  outer in member http://www.openstreetmap.org/browse/way/152517650 
OSM Warning:http://www.openstreetmap.org/browse/relation/2036496 Unknown role  outer in member http://www.openstreetmap.org/browse/way/151093063 
OSM Warning:http://www.openstreetmap.org/browse/relation/2036496 Unknown role  outer in member http://www.openstreetmap.org/browse/way/151093146 
OSM Warning:http://www.openstreetmap.org/browse/relation/2036496 Unknown role  inner in member http://www.openstreetmap.org/browse/way/151093201 
OSM Warning:http://www.openstreetmap.org/browse/relation/2063615 Unknown role nt in member http://www.openstreetmap.org/browse/way/137325269 
OSM Info:http://www.openstreetmap.org/browse/relation/2067731 Country Boundary for 'th'
OSM Info:http://www.openstreetmap.org/browse/relation/2088990 Country Boundary for 'RS'
OSM Warning:http://www.openstreetmap.org/browse/relation/2090329 Unknown role innrt in member http://www.openstreetmap.org/browse/way/155787948 
OSM Warning:http://www.openstreetmap.org/browse/relation/2090329 Unknown role innrt in member http://www.openstreetmap.org/browse/way/155787938 
add_segment: error
OSM Warning:http://www.openstreetmap.org/browse/relation/49898 Broken country polygon 'kh'
OSM Warning:http://www.openstreetmap.org/browse/relation/184843 Broken country polygon 'lb'
OSM Warning:http://www.openstreetmap.org/browse/relation/192691 Broken country polygon 'ma'
OSM Warning:http://www.openstreetmap.org/browse/relation/192757 Broken country polygon 'tn'
OSM Warning:http://www.openstreetmap.org/browse/relation/192788 Broken country polygon 'td'
OSM Warning:http://www.openstreetmap.org/browse/relation/192830 Broken country polygon 'cm'
OSM Warning:http://www.openstreetmap.org/browse/relation/195270 Broken country polygon 'tz'
OSM Warning:http://www.openstreetmap.org/browse/relation/195838 Broken country polygon 'eh'
OSM Warning:http://www.openstreetmap.org/browse/relation/270056 Broken country polygon 'cn'
OSM Warning:http://www.openstreetmap.org/browse/relation/272644 Broken country polygon 've'
OSM Warning:http://www.openstreetmap.org/browse/relation/288247 Broken country polygon 'pe'
OSM Warning:http://www.openstreetmap.org/browse/relation/304716 Broken country polygon 'in'
OSM Warning:http://www.openstreetmap.org/browse/relation/307573 Broken country polygon 'pk'
./navitmap-planet: Zeile 8:  6390 Speicherzugriffsfehler  maptool --protobuf -i planet-latest.osm.pbf navitmap-planet.bin

Changed 6 years ago by tegzed

fixed intersection detection for horizontal and vertical lines

comment:100 Changed 6 years ago by fred jelk

thanks tegzed... (cool, that you're updated to svn-5005... so the meadows would also be rendered now.
I'll try the planet this evening again.

comment:101 Changed 6 years ago by tegzed

Hi Wakefred,

The planet will probably crash with this patch too, we still have at least one bug that will prevent building planet with this patch. The triangulator code is very touchy about the input polygons and I keep running into exotic cases. Hopefully I can eliminate all the problemmatic cases soon.

comment:102 Changed 6 years ago by tegzed

One problemmatic polygon is http://www.openstreetmap.org/?relation=1175564 but when I try to export this area from the osm the server gives me an error. I would need a small extract to fix a bug so I don't need to wait more than one day to debug this poly. Can anybody get osm xlm data for this area?

comment:103 Changed 6 years ago by korrosa

On Sunday 1st April OSM changed its licensing from CC-BY-SA to ODBL. The servers are currently undergoing maintenance until April 4th, so service will be poor.

comment:104 Changed 6 years ago by fred jelk

I can extract this area tomorrow morning from the planet, if you like. But you can't upload a changed polygon till 04.April, because the OSM-database is at the moment just in a read-only-mode.

comment:105 Changed 6 years ago by tegzed

I just want the osm xlm data for testing an as small as possible area, I don't want to upload any modifications to osm. It would be very helpful for me if you could extract this area from the planet.

comment:106 Changed 6 years ago by fred jelk

@tegzed... the planet is still at work. and the multipolygon 1175564 is attached: http://trac.navit-project.org/attachment/ticket/754/defect_multipolygon.osm

Changed 6 years ago by fred jelk

for testing

comment:107 Changed 6 years ago by fred jelk

@tegzed... as you said: the planet don't work.
Message:

./navitmap-planet: Zeile 8: 15647 Speicherzugriffsfehler  maptool --protobuf -i planet-latest.osm.pbf navitmap-planet.bin

comment:108 Changed 6 years ago by rico

Is there any chance to get the patch into svn?

comment:109 Changed 6 years ago by tegzed

Hi Rico,

I need to fix some problems with the patch since planet osm crashes with it and arrange the code to a better shape. These weeks I'm quite busy but I hope to find the time for this soon.

comment:110 Changed 5 years ago by usul

Over at the new forum, somebody asks if/when this patch can be applied or if there are other workarounds: https://forum.navit-project.org/viewtopic.php?f=4&t=396

comment:111 Changed 5 years ago by rico (2)

I tried to adapt the patch to svn 5532 and it seems to works at least for germany. http://linux.bierrommel.de/dateien/navit/multipolygon.patch

comment:112 Changed 5 years ago by tryagain

Hi,

As tegzed said in http://trac.navit-project.org/ticket/754#comment:109, this patch will crash on the whole planet. Though I have not verified that.

As far as I can see from the code, it makes one navit item from the whole relation. For large rivers/lakes, these objects can be quite big in terms of node count (resulting in tens or even hundreds of kilobytes size). Also, large objects will cross tiles boundaries so they will be put into the upper level tiles, significantly affecting all map operations on the target device. For example, a river crossing the Equator will be processed even when you're in Germany, resulting in raised memory requirements and slowed down processing speed.

So I think we should consider another approach, similar to the one used in coastline processing. Whole set of ways tagged natural=coastline is very similar to one huge multimegabyte boundary relation. The only difference is that all natural=coastline ways have consistent direction.

But we already have in maptool a function to fix boundary members directions. This mechanism is proven to work on administrative boundary relations and is giving good results now.

I think a working approach would be to mix these two existing solutions: one for administrative boundaries to make each relation look like a coastline set. And then process each resulting "coastline" to split it into the pieces on the tile boundaries.

tryagain.

Changed 4 years ago by usul

Changed 4 years ago by usul

comment:113 Changed 4 years ago by usul

  • Cc cp15 added
  • Keywords multi poly water coast added
  • Milestone set to version 0.5.1

Maybe this area in Germany can be a good usecase:

I had a chat with cp15 and he said that there is some algorithm to draw multipolygones the right way, without the need to do some preprocessing (as far as I understood).

As this issue might confuse users and think that Navit is broken, I schedule it to next hotfix release 0.5.1

comment:114 Changed 2 weeks ago by http://wiki.navit-project.org/index.php/user:jkoan

  • Milestone changed from version 0.5.1 to version 0.5.2

This ticket was pushed back in order to bring 0.5.1 out soon.

Note: See TracTickets for help on using tickets.