[PATCH v8] - alpha patch to support road find by name
v9 - based on r985. Now tries to reduce (connected) groups of roads with the same name and city to just one entry - please test. If you find that you are still seeing multiple entries for a road, check the OSM data to see that the road really is sensibly defined, i.e. it's quite possible to have a bunch of connected road segments some of which have the same name and the others having no name - in that case, the road will get listed more than once. Also, dual carriageways will show up as two entries. Feedback/comments welcome. ----------- Hi, The attached patch is for the current SVN trunk and it generates the sorted road data that is required by the gps to find roads/intersections by name. As for the number field, I haven't thought yet how that would get its data. Please test this patch and report success/failure. If it doesn't break anything for anyone, I would like to commit it fairly soon as I think that quite a few people will be happy to have street finding added to the trunk. Cheers, Mark
Hello Mark, On Sun, Mar 22, 2009 at 11:16:57PM +0000, Mark Burton wrote:
v9 - based on r985. Now tries to reduce (connected) groups of roads with the same name and city to just one entry - please test.
Works for me. Some further observations about the incremental street name search. When I search for a road with ref=1521, as I type "1", the list will display both the road with ref=1 and road names starting with "1". (In Finland, street numbers come after the road name. Thus, a street name can start with a number.) When I type "15", I only see "15" on the list. Likewise for "152" and "1521". (All these roads exist. If I type a digit after 1521, then there won't be matches.) Also, when I type "E 7", the list only displays "7" (without the E). With "E 75", it will display "E 75" as the only entry. I'm beginning to think that Garmin has implemented it like this on purpose. I didn't try adding any post code (zip) data yet. I have some remarks on the patch itself.
@@ -71,6 +71,7 @@ <javac srcdir="${src}" destdir="${build.classes}" target="1.5" debug="true"> <include name="**/*.java" /> <classpath refid="main"/> + <!-- <compilerarg value="-Xlint:unchecked"/> --> </javac> </target>
Are you planning to uncomment this and fix the warnings?
+ public int compareTo(Object other) { + Label o = (Label)other; + if(this == other) + return 0; + for(int i = 0; i < length && i < o.length; ++i) { + int diff = (ctext[i] & 0xff) - (o.ctext[i] & 0xff); + if(diff != 0) + return diff; + } + if(length == o.length) + return 0; + return (length > o.length)? 1 : -1; + }
Have you tested with non-ASCII data that this is what Garmin expects? Which character set is ctext[] in? What about the Sortable<String, ?> introduced in the patch? Is the String in Unicode as usual? Will the collation be compatible with Garmin's? Will it depend on the locale setting?
@@ -41,10 +40,23 @@ public class Region { }
public char getIndex() { + assert index > 0 : "Index not yet set"; return index; }
+ public Country getCountry() { + return country; + } + + public void setIndex(int index) { + this.index = (char)index; + } +
Should setIndex assert that the index must not be set twice? Best regards, Marko
Hi Marko,
On Sun, Mar 22, 2009 at 11:16:57PM +0000, Mark Burton wrote:
v9 - based on r985. Now tries to reduce (connected) groups of roads with the same name and city to just one entry - please test.
Works for me.
Good.
Some further observations about the incremental street name search. When I search for a road with ref=1521, as I type "1", the list will display both the road with ref=1 and road names starting with "1". (In Finland, street numbers come after the road name. Thus, a street name can start with a number.) When I type "15", I only see "15" on the list. Likewise for "152" and "1521". (All these roads exist. If I type a digit after 1521, then there won't be matches.) Also, when I type "E 7", the list only displays "7" (without the E). With "E 75", it will display "E 75" as the only entry.
I'm beginning to think that Garmin has implemented it like this on purpose.
I think it's just plain broken!
I didn't try adding any post code (zip) data yet.
I have some remarks on the patch itself.
@@ -71,6 +71,7 @@ <javac srcdir="${src}" destdir="${build.classes}" target="1.5" debug="true"> <include name="**/*.java" /> <classpath refid="main"/> + <!-- <compilerarg value="-Xlint:unchecked"/> --> </javac> </target>
Are you planning to uncomment this and fix the warnings?
I was trying to remove the warnings in Sortable but have not yet managed to remove them all. I don't care too much (as it works as expected) and there are quite a few other unchecked warnings, so I shall probably not spend much time on that.
+ public int compareTo(Object other) { + Label o = (Label)other; + if(this == other) + return 0; + for(int i = 0; i < length && i < o.length; ++i) { + int diff = (ctext[i] & 0xff) - (o.ctext[i] & 0xff); + if(diff != 0) + return diff; + } + if(length == o.length) + return 0; + return (length > o.length)? 1 : -1; + }
Have you tested with non-ASCII data that this is what Garmin expects?
No.
Which character set is ctext[] in? What about the Sortable<String, ?> introduced in the patch? Is the String in Unicode as usual? Will the collation be compatible with Garmin's? Will it depend on the locale setting?
Haven't a clue about any of that. But when people around the world test this patch and report back, we will know whether it's doing the right thing or not. I am ready to act on reports of it not working as expected.
@@ -41,10 +40,23 @@ public class Region { }
public char getIndex() { + assert index > 0 : "Index not yet set"; return index; }
+ public Country getCountry() { + return country; + } + + public void setIndex(int index) { + this.index = (char)index; + } +
Should setIndex assert that the index must not be set twice?
The answer to that depends on how paranoid you are. I can cope with there not being an assert there because I know how that method is being invoked. Cheers, Mark
On Mon, Mar 23, 2009 at 08:57:24AM +0000, Mark Burton wrote:
Some further observations about the incremental street name search. When I search for a road with ref=1521, as I type "1", the list will display both the road with ref=1 and road names starting with "1". (In Finland, street numbers come after the road name. Thus, a street name can start with a number.) When I type "15", I only see "15" on the list. Likewise for "152" and "1521". (All these roads exist. If I type a digit after 1521, then there won't be matches.) Also, when I type "E 7", the list only displays "7" (without the E). With "E 75", it will display "E 75" as the only entry.
I'm beginning to think that Garmin has implemented it like this on purpose.
I think it's just plain broken!
Come to think of it, could this be a collation problem? What happens if you have the street names Aa, Aac, Aab, Aaa sorted in that order while Garmin expects Aa, Aaa, Aab, Aac, and you type "AA"? Will it only display the "Aa"? Do you have a copy of a map where the incremental search of street names containing numbers does work? If yes, can you extract the labels from there and infer (some of) the collation? Specifically, I'm suspecting that one of the collations (mkgmap, Garmin) could be sorting 0-9 before A-Z and the other could be sorting 0-9 after A-Z. [snip]
Haven't a clue about any of that. But when people around the world test this patch and report back, we will know whether it's doing the right thing or not. I am ready to act on reports of it not working as expected.
Right, with open source you can outsource the testing. I feel that the patch is good enough to be committed. The small imperfections can be ironed out later.
Should setIndex assert that the index must not be set twice?
The answer to that depends on how paranoid you are. I can cope with there not being an assert there because I know how that method is being invoked.
When working on complex pieces of software, I've been peppering the code quite liberally with assertions. They don't hurt performance on production environments when you compile (or in the case of Java, run) with the right flags. And they can save a lot of trouble later. Marko
Hi Marko, On Mon, 23 Mar 2009 22:44:00 +0200 Marko Mäkelä <marko.makela@iki.fi> wrote:
On Mon, Mar 23, 2009 at 08:57:24AM +0000, Mark Burton wrote:
Some further observations about the incremental street name search. When I search for a road with ref=1521, as I type "1", the list will display both the road with ref=1 and road names starting with "1". (In Finland, street numbers come after the road name. Thus, a street name can start with a number.) When I type "15", I only see "15" on the list. Likewise for "152" and "1521". (All these roads exist. If I type a digit after 1521, then there won't be matches.) Also, when I type "E 7", the list only displays "7" (without the E). With "E 75", it will display "E 75" as the only entry.
I'm beginning to think that Garmin has implemented it like this on purpose.
I think it's just plain broken!
Come to think of it, could this be a collation problem? What happens if you have the street names Aa, Aac, Aab, Aaa sorted in that order while Garmin expects Aa, Aaa, Aab, Aac, and you type "AA"? Will it only display the "Aa"?
Do you have a copy of a map where the incremental search of street names containing numbers does work? If yes, can you extract the labels from there and infer (some of) the collation? Specifically, I'm suspecting that one of the collations (mkgmap, Garmin) could be sorting 0-9 before A-Z and the other could be sorting 0-9 after A-Z.
I have checked maps created by cgpsmapper and the sorting appears similar (digits before letters).
[snip]
Haven't a clue about any of that. But when people around the world test this patch and report back, we will know whether it's doing the right thing or not. I am ready to act on reports of it not working as expected.
Right, with open source you can outsource the testing. I feel that the patch is good enough to be committed. The small imperfections can be ironed out later.
Actually, I do test most of the code I write before I push it to the list but as we're making maps here and not building moon rockets, it's probably not too serious if it doesn't quite work right first time for some poor alpha tester who uses a different locale/charset. They'll soon say if it doesn't work and it can get fixed up.
Should setIndex assert that the index must not be set twice?
The answer to that depends on how paranoid you are. I can cope with there not being an assert there because I know how that method is being invoked.
When working on complex pieces of software, I've been peppering the code quite liberally with assertions. They don't hurt performance on production environments when you compile (or in the case of Java, run) with the right flags. And they can save a lot of trouble later.
No doubt, but I'm comfortable with the piece of code in question not having an assertion to check if the index has been set twice because: 1 - that method is only called from one place. 2 - the code that calls that method is trivial and unlikely to suffer weird errors. 3 - I prefer to use assertions only in those places where I believe there is some doubt as to the correctness of the code (or the data being manipulated by the code). I generally don't use them as a general backstop to catch sloppy programming or conceptual screwups - after all, that's what exceptions are for (discuss). Cheers, Mark
On Sun, Mar 22, 2009 at 11:16:57PM +0000, Mark Burton wrote:
v9 - based on r985. Now tries to reduce (connected) groups of roads with the same name and city to just one entry - please test.
If you find that you are still seeing multiple entries for a road, check the OSM data to see that the road really is sensibly defined, i.e. it's quite possible to have a bunch of connected road segments some of which have the same name and the others having no name - in that case, the road will get listed more than once. Also, dual carriageways will show up as two entries.
Feedback/comments welcome.
A little nitpick (Its always possible to optimize something :) )
+ // given a list of roads sorted by name and city, build a new + // list that only contains one entry for each group of roads + // that have the same name and city and are directly connected
As it happens i live in a street which is intersected by a roundabout. As the roundabout does not have the street name on it this will produce multiple segments. So probably it should be directly connected or via a way with "junction=roundabout" ... But this is just a little optimization probably for the next generation ;) Flo -- Florian Lohoff flo@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin
Hi Florian, Thanks for testing the patch.
A little nitpick (Its always possible to optimize something :) )
Nitpicks are fine.
+ // given a list of roads sorted by name and city, build a new + // list that only contains one entry for each group of roads + // that have the same name and city and are directly connected
As it happens i live in a street which is intersected by a roundabout. As the roundabout does not have the street name on it this will produce multiple segments. So probably it should be directly connected or via a way with "junction=roundabout" ...
But this is just a little optimization probably for the next generation ;)
I am sure that some people would prefer that the two roads are not squashed together in that situation because it would "hide" one of the roads and so they may think that the one road that has been shown stops at the roundabout when, in reality, it carries on past the roundabout. So, given that it's a bunch of work to implement and I'm not convinced it would be universally popular, I will leave that for someone else to add. Cheers, Mark
On Sun, Mar 22, 2009 at 11:16:57PM +0000, Mark Burton wrote:
Subject: [mkgmap-dev] [PATCH v8] - alpha patch to support road find by name
v9 - based on r985. Now tries to reduce (connected) groups of roads with the same name and city to just one entry - please test.
If you find that you are still seeing multiple entries for a road, check the OSM data to see that the road really is sensibly defined, i.e. it's quite possible to have a bunch of connected road segments some of which have the same name and the others having no name - in that case, the road will get listed more than once. Also, dual carriageways will show up as two entries.
Feedback/comments welcome.
I have another one - i wasnt actually shure whats going on but it seems that when using the splitter - converting the osm files individually with mkgmap and later merging them with mkgmap to a gmapsupp the ability to search for streets gets lost - i get a list shown which contains my example street "Alt Hammoor" but when searching by entering characters "AL" the list is empty - Entering "Al" does not work (GPSMap 60Csx) because pressing ok on the lower case "l" does not cause it to be added to the search string. I remember i was able to find "Alt Hammoor" by entering "ALT" ... I'll convert a smaller subset without splitting and merging... Flo -- Florian Lohoff flo@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin
On Mon, Mar 23, 2009 at 08:10:59PM +0100, Florian Lohoff wrote:
I have another one - i wasnt actually shure whats going on but it seems that when using the splitter - converting the osm files individually with mkgmap and later merging them with mkgmap to a gmapsupp the ability to search for streets gets lost - i get a list shown which contains my example street "Alt Hammoor" but when searching by entering characters "AL" the list is empty - Entering "Al" does not work (GPSMap 60Csx) because pressing ok on the lower case "l" does not cause it to be added to the search string.
I remember i was able to find "Alt Hammoor" by entering "ALT" ...
I'll convert a smaller subset without splitting and merging...
I am able to find it in the smaller subset - strange ... This is how i convert the single small subset: java -Xmx1024M -jar /home/flo/export2garmin/mkgmap-r986/dist/mkgmap.jar --net --route --tdbfile --gmapsupp owl.osm This is how i convert the larger subset with splitting: java -jar ../splitter-r27/dist/splitter.jar nordrhein-westfalen.osm for i in *.osm.gz; do echo Converting $i java -Xmx1024M \ -jar /home/flo/export2garmin/mkgmap-r986/dist/mkgmap.jar \ --net --route $i done java -Xmx1024M -jar /home/flo/export2garmin/mkgmap-r986/dist/mkgmap.jar \ --net --route --gmapsupp --tdbfile *.img Flo -- Florian Lohoff flo@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin
On Mon, Mar 23, 2009 at 08:10:59PM +0100, Florian Lohoff wrote:
I have another one - i wasnt actually shure whats going on but it seems that when using the splitter - converting the osm files individually with mkgmap and later merging them with mkgmap to a gmapsupp the ability to search for streets gets lost - i get a list shown which contains my example street "Alt Hammoor" but when searching by entering characters "AL" the list is empty - Entering "Al" does not work (GPSMap 60Csx) because pressing ok on the lower case "l" does not cause it to be added to the search string.
I remember i was able to find "Alt Hammoor" by entering "ALT" ...
I'll convert a smaller subset without splitting and merging...
My fault - used v8 instead of v9 Flo -- Florian Lohoff flo@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin
participants (3)
-
Florian Lohoff -
Mark Burton -
Marko Mäkelä