[PATCH v6] - Code around highway shield crap when sorting labels
v6 - don't trash first ref if it is the same as the name (sans shield) and more refs follow --------- v5 - now understands the 0x1b prefix code that introduces a lower case letter (and also is used to prefix a couple of separators (0x1b and 0x1c). I thought great, now I can prefix my road names with ^\ (aka 0x1c) and they won't show up so readily when zoomed out. That worked as expected but, unfortunately, it broke the address search stuff so the bottom line is that you can't use the separators as a prefix (sob). Also, for those of you wondering why the display names and other refs are not showing up in the mapsource address search - it's because the MDR building code only reads the first label for a road and ignores any others. Shame that. I don't think there's a good reason why it couldn't read the other labels, it's just doesn't do that at the moment. BTW - the basic address search on the etrex and Nuvi still sees those alternative road labels. So, those people who are tracking this patch series, please test and if it doesn't bite your arse, I will commit it soonish -------- v4 - found the motorways (and a load of other roads too!) -------- v3 - now works harder to clean up road names for use in MDR file - not sure if this will have a beneficial effect but it could possibly fix the issue recently reported by Felix. Motorways are still not showing up. ------- v2 - remove more duplicate labels that only differ in letter case - remove leading spaces from labels even if they start with a Garmin code. Still something wrong with motorway names because on the UK map, only the M74 appears in the mapsource road names - all other motorways are missing - very odd. ------- This patch codes around the problems introduced by highway shields with regard to the sorted roads: 1 - the sort order should now be much improved 2 - no duplicate symbols (shield version + non-shield version) It also includes a fix to the label reading code so that labels with a highway shield prefix are read in correctly when generating the MDR file. For me, in mapsource, road search for roads with highway shields now works apart from motorways which don't seem to searchable - perhaps that's deliberate on Garmin's part? All feedback appreciated. Mark
On 22.03.2010 00:42, Mark Burton wrote:
v6 - don't trash first ref if it is the same as the name (sans shield) and more refs follow
--------- In principle the patch works very good. I do get complications when using this patch in combination to Wan Mill's "mp_lesscuts_v4.patch".
It would be great if the following patches could be added to trunk, for me they all work very well: empty_labels.patch mp_lesscuts_v4.patch (causes some problems in combination with above patch v6) mp_rolehandling_v3.patch sizeFilter.patch (previously called drop_small_polygons.patch) I'm attaching them all here, in order for no need to search the ML Here is the error I'm getting with patch v6 and mp_lesscuts D:\Garmin\mkgmap_680\maps>start /low /b /wait java -ea -jar -Xmx1250M d:\garmin\mkgmap_680\mkgmap.jar --style-file=d:\garmin\mkgmap_680\new4 --max-jobs=3 --generate-sea=polygons,extend-sea-sectors,close-gaps=6000 --reduce-point-density=5.4 --reduce-point-density-polygon=8 --suppress-dead-end-nodes --index --delete-tags-file=d:\garmin\mkgmap_680\new4\deletetags --transparent --blacklist-tags-file=deletetags --adjust-turn-headings --ignore-maxspeeds --ignore-turn-restrictions --remove-short-arcs=4 --description=openmtbmap_at --location-auto fill=2 --route --country-abbr=at --country-name=austria --mapname=63220000 --family-id=6322 --product-id=1 --series-name=openmtbmap_at_22.03.2010 --family-name=mtbmap_at_22.03.2010 --tdbfile --overview-mapname=mapset --area-name="austria_22.03.2010_openmtbmap.org" -c d:\g armin\mkgmap_680\maps\template.args java.lang.NullPointerException at uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.closeWays(MultiPolygonRelation.java:327) at uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.processElements(MultiPolygonRelation.java:538) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5XmlHandler.endRelation(Osm5XmlHandler.java:594) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5XmlHandler.endElement(Osm5XmlHandler.java:564) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601) at com.sun.org.apache.xerces.internal.xinclude.XIncludeHandler.endElement(XIncludeHandler.java:1014) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1774) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2930) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) at javax.xml.parsers.SAXParser.parse(SAXParser.java:395) at javax.xml.parsers.SAXParser.parse(SAXParser.java:198) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5MapDataSource.java:81) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:148) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:189) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:186) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Exiting - if you want to carry on regardless, use the --keep-going option D:\Garmin\mkgmap_680\maps>echo end 15:13:00 1>>time.log
Hi Felix,
On 22.03.2010 00:42, Mark Burton wrote:
v6 - don't trash first ref if it is the same as the name (sans shield) and more refs follow
--------- In principle the patch works very good.
Good.
I do get complications when using this patch in combination to Wan Mill's "mp_lesscuts_v4.patch".
Isn't that patch already in the trunk?
It would be great if the following patches could be added to trunk, for me they all work very well: empty_labels.patch
This is also in trunk now.
mp_lesscuts_v4.patch (causes some problems in combination with above patch v6)
mp_rolehandling_v3.patch sizeFilter.patch (previously called drop_small_polygons.patch)
Don't know the status of those patches.
java.lang.NullPointerException at uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.closeWays(MultiPolygonRelation.java:327) at uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.processElements(MultiPolygonRelation.java:538)
Actually, if you look at the code, that NPE should be impossible to achieve. Something very odd is happening - can you try again using a clean build (ant clean; ant) Mark
On 22.03.2010 15:29, Mark Burton wrote:
Hi Felix,
On 22.03.2010 00:42, Mark Burton wrote:
v6 - don't trash first ref if it is the same as the name (sans shield) and more refs follow
---------
In principle the patch works very good.
Good.
I do get complications when using this patch in combination to Wan Mill's "mp_lesscuts_v4.patch".
Isn't that patch already in the trunk?
I don't think so, based on nearly no complications on trying to add it.
It would be great if the following patches could be added to trunk, for me they all work very well: empty_labels.patch
This is also in trunk now.
And how comes that I can still apply it - without it being there yet?
mp_lesscuts_v4.patch (causes some problems in combination with above patch v6)
mp_rolehandling_v3.patch sizeFilter.patch (previously called drop_small_polygons.patch)
Don't know the status of those patches.
java.lang.NullPointerException at uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.closeWays(MultiPolygonRelation.java:327) at uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.processElements(MultiPolygonRelation.java:538)
Actually, if you look at the code, that NPE should be impossible to achieve. Something very odd is happening - can you try again using a clean build (ant clean; ant)
I do that before every compile. As soon as I add mp_lesscuts_v4 it happens.
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
I do get complications when using this patch in combination to Wan Mill's "mp_lesscuts_v4.patch".
Isn't that patch already in the trunk?
I don't think so, based on nearly no complications on trying to add it.
See attached pic - the commits "v4 of the patch..." and "Treat a label..." are what we are talking about. They are definitely on the master branch (aka trunk). Mark
participants (2)
-
Felix Hartmann -
Mark Burton