Re: [mkgmap-dev] mkgmap creates polygons that break Mapsource panning and also routing in some zoomlevels as well as crashing the GPS
Felix,
Okay, here are the output files. Once including the problematic landuse=* line, once without.
Thanks. Unfortunately, they have too much other crap in them and not enough of what I want to see. Did you use the logging.properties file I sent to you? Mark
Mark Burton wrote:
Felix,
Okay, here are the output files. Once including the problematic landuse=* line, once without.
Thanks. Unfortunately, they have too much other crap in them and not enough of what I want to see. Did you use the logging.properties file I sent to you?
Ups, sorry, here is the output using logging.properties: again broken vs not broken
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix,
Ups, sorry, here is the output using logging.properties:
again broken vs not broken
OK, thanks for those. They are interesting because they differ less than I expected but in an unexpected way (work that one out!) I want to double check so please apply v3 of patch (attached) and recreate the log files for the bad and good styles. Also, do those styles only differ in the number of polygon styles they contain or do the number of points and lines change as well? Thanks, Mark
Ahh, you're adding POIs to areas, aren't you. Have you tried building with that option turned off?
Felix, Wild guess here: I wondered if the POI index was overflowing and trashing some other stuff because in the bad map example you sent, it contained just over 32K entries. So commit 1170 disables POI index generation. It wasn't useful anyway, so that's no loss. Please see if that makes any difference. Mark
Mark Burton wrote:
Felix,
Wild guess here: I wondered if the POI index was overflowing and trashing some other stuff because in the bad map example you sent, it contained just over 32K entries. So commit 1170 disables POI index generation. It wasn't useful anyway, so that's no loss. Please see if that makes any difference.
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
thanks for your work, by now I am sure (100%) which polygon was fucking up (as so far as being the main cause). It's the forest here: http://www.openstreetmap.org/?lat=47.70079&lon=16.18152&zoom=16&layers=B000F.... I have attached a screenshot of it' rendering in Mapsource. If you set detail level to lowest, decrease the mapsource window size (e.g. to 240x240 pixels only), and then pan to it, you will notice that you can still display it partly, but near to the center will crash. It was (I corrected it) connected at around 30 places to streets. On top of it sometimes lines were parallel in order to draw holes into the forest, so the intent here must have been to not show it at certain places. Even though this is bad tagging practice, mkgmap should not create maps that send gps into rebot/crash, and also send mapsource 6.13.7 and before into big problems. I am sure it was not the POI index overflowing, but has to do with nodes shared between streets and polygon. I have no clue why Mapsource suffocates on that forest if streets are attached to it in osm database. Excluding rendering of the streets that shared nodes with the forest would have the same effect as not rendering the forest at all or skipping rendering another forest that was partly overlaying at the same place. Well maybe you can still find out, Find in the new download: 1. Again the osm tile (I do hope my edits mean that tomorrow it will render without problems (disconnected all streets and administrative boarders, and corrected some of the nearly parallel lines). 2. not working with areas-pois 3. not working without without areas-pois 4. working excluding any rendering of wood=mixed & fixme=* and excluding landuse=forest & fixme=*, with areas-pois 2-4 consisting of tile plus log. Get files for analysis (35MB) here: http://openmtbmap.org/downloads/polygon_problem.zip Felix
Hi Felix,
thanks for your work,
You're welcome.
by now I am sure (100%) which polygon was fucking up (as so far as being the main cause). It's the forest here: http://www.openstreetmap.org/?lat=47.70079&lon=16.18152&zoom=16&layers=B000F.... I have attached a screenshot of it' rendering in Mapsource. If you set detail level to lowest, decrease the mapsource window size (e.g. to 240x240 pixels only), and then pan to it, you will notice that you can still display it partly, but near to the center will crash.
It was (I corrected it) connected at around 30 places to streets. On top of it sometimes lines were parallel in order to draw holes into the forest, so the intent here must have been to not show it at certain places.
Even though this is bad tagging practice, mkgmap should not create maps that send gps into rebot/crash, and also send mapsource 6.13.7 and before into big problems. I am sure it was not the POI index overflowing, but has to do with nodes shared between streets and polygon.
Lots of maps share nodes between roads and polygons and don't have problems so there's more to this than just that.
I have no clue why Mapsource suffocates on that forest if streets are attached to it in osm database. Excluding rendering of the streets that shared nodes with the forest would have the same effect as not rendering the forest at all or skipping rendering another forest that was partly overlaying at the same place.
Not sure what you're saying here. Did you mean that you could generate a map that had either the forest or the streets but not both together?
Well maybe you can still find out, Find in the new download: 1. Again the osm tile (I do hope my edits mean that tomorrow it will render without problems (disconnected all streets and administrative boarders, and corrected some of the nearly parallel lines). 2. not working with areas-pois 3. not working without without areas-pois 4. working excluding any rendering of wood=mixed & fixme=* and excluding landuse=forest & fixme=*, with areas-pois 2-4 consisting of tile plus log.
Get files for analysis (35MB) here: http://openmtbmap.org/downloads/polygon_problem.zip
Thanks for putting that together. I am studying it but have nothing to report at this time. Is it easy to produce for me the osm file for just that forest region (before your recent edits)? If so, please do that because I would like to look at the osm data but the tile you sent me is too big for me to load into josm. I guess I could use the splitter on that file to extract the forest region. Cheers, Mark
Mark Burton wrote:
Hi Felix,
thanks for your work,
You're welcome.
by now I am sure (100%) which polygon was fucking up (as so far as being the main cause). It's the forest here: http://www.openstreetmap.org/?lat=47.70079&lon=16.18152&zoom=16&layers=B000F.... I have attached a screenshot of it' rendering in Mapsource. If you set detail level to lowest, decrease the mapsource window size (e.g. to 240x240 pixels only), and then pan to it, you will notice that you can still display it partly, but near to the center will crash.
It was (I corrected it) connected at around 30 places to streets. On top of it sometimes lines were parallel in order to draw holes into the forest, so the intent here must have been to not show it at certain places.
Even though this is bad tagging practice, mkgmap should not create maps that send gps into rebot/crash, and also send mapsource 6.13.7 and before into big problems. I am sure it was not the POI index overflowing, but has to do with nodes shared between streets and polygon.
Lots of maps share nodes between roads and polygons and don't have problems so there's more to this than just that.
I have no clue why Mapsource suffocates on that forest if streets are attached to it in osm database. Excluding rendering of the streets that shared nodes with the forest would have the same effect as not rendering the forest at all or skipping rendering another forest that was partly overlaying at the same place.
Not sure what you're saying here. Did you mean that you could generate a map that had either the forest or the streets but not both together?
Yes. On top of it without a typfile showing either, it will work too. ( I think this is related to the extended types, that (at least the types I have chosen) will not display at all if not defined in the .TYPfile.)
Well maybe you can still find out, Find in the new download: 1. Again the osm tile (I do hope my edits mean that tomorrow it will render without problems (disconnected all streets and administrative boarders, and corrected some of the nearly parallel lines). 2. not working with areas-pois 3. not working without without areas-pois 4. working excluding any rendering of wood=mixed & fixme=* and excluding landuse=forest & fixme=*, with areas-pois 2-4 consisting of tile plus log.
Get files for analysis (35MB) here: http://openmtbmap.org/downloads/polygon_problem.zip
Thanks for putting that together. I am studying it but have nothing to report at this time.
Is it easy to produce for me the osm file for just that forest region (before your recent edits)? If so, please do that because I would like to look at the osm data but the tile you sent me is too big for me to load into josm. I guess I could use the splitter on that file to extract the forest region.
I will try to split it with very small max-nodes to get the size down, and also have a look if todays austria extract compiles clean. More later
Cheers,
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix, Please try the attached patch on the original tile and see if it fixes the problem. Cheers, Mark
Mark Burton wrote:
Hi Felix,
Please try the attached patch on the original tile and see if it fixes the problem.
Cheers,
Mark
------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev Yeah great, Finally fixed. I could not find any errors in the map.
I think you should submit that patch, maybe there exist other evil places.... I had just prepared a supersmall tile for you to work with but ironically on that supersmall (max-nodes 20000) tile installed alone (200kb .img size, 2MB osm unpacked) mapsource would not have problems.
Yeah great, Finally fixed. I could not find any errors in the map.
That's good. The problem was that a polygon was being generated that only contained 2 points. The more recent mapsource versions must ignore degenerate polygons (and lines as well, presumably) but the older mapsource and at least some gps units barfed. I have committed the fix. I am still looking to get some feedback on the subdiv fixes patch I posted yesterday, please try it out if possible as I believe that they are an improvement. Cheers, Mark
Mark Burton wrote:
Yeah great, Finally fixed. I could not find any errors in the map.
That's good.
The problem was that a polygon was being generated that only contained 2 points. The more recent mapsource versions must ignore degenerate polygons (and lines as well, presumably) but the older mapsource and at least some gps units barfed.
I have committed the fix.
I am still looking to get some feedback on the subdiv fixes patch I posted yesterday, please try it out if possible as I believe that they are an improvement.
I was all the time using it without problems. I don't know whether there have been improvements, but nothing became worse in any case. I subjectively think map panning got a tiny bit quicker, but might be mistaken.
Cheers,
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
I was all the time using it without problems. I don't know whether there have been improvements, but nothing became worse in any case. I subjectively think map panning got a tiny bit quicker, but might be mistaken.
Ok, good. If the patch is working right, it should be reducing the number of subdivisions being created so it may well make map display a little quicker. Cheers, Mark
participants (2)
-
Felix Hartmann -
Mark Burton