address index glitch?
the address index lookup seems to work fine except for this one glitch. i enter a house number, then select a road. the road comes up as the destination with no house number displayed, and the routing is to the approximate center point of the road. so for some reason the house number is being discarded in the lookup process. mkgmap is r2379, garmin is a nuvi 255w. from my current build script: java -enableassertions \ -Xmx2048m \ -jar ~/Projects/mkgmap/mkgmap-r2379/mkgmap.jar \ --index \ --gmapsupp \ --remove-short-arcs \ --description="Capital District ER Map Prototype" \ --add-pois-to-areas \ --route \ --overview-mapname=63600000 \ --mapname=63600001 \ --family-id=787 \ --product-id=15 \ --family-name="OSM ER 2012" \ --country-abbr="US" \ --country-name="United States" \ --region-abbr="NY" \ --region-name="New York" \ --series-name="OSM ER Test Series" \ --area-name="Capital District NY" \ --link-pois-to-ways \ --adjust-turn-headings \ --drive-on-right \ --check-roundabouts \ --check-roundabout-flares \ --add-pois-to-areas \ --location-autofill \ $1 any suggestions as to what's up? thanks, richard
AFAIK house numbers are not coded in mkgmap, so you can't use them. In the devices you will have to enter a fake house number in some searches though. El 24/11/12 20:30, Richard Welty escribió:
the address index lookup seems to work fine except for this one glitch. i enter a house number, then select a road. the road comes up as the destination with no house number displayed, and the routing is to the approximate center point of the road.
so for some reason the house number is being discarded in the lookup process.
mkgmap is r2379, garmin is a nuvi 255w. from my current build script:
java -enableassertions \ -Xmx2048m \ -jar ~/Projects/mkgmap/mkgmap-r2379/mkgmap.jar \ --index \ --gmapsupp \ --remove-short-arcs \ --description="Capital District ER Map Prototype" \ --add-pois-to-areas \ --route \ --overview-mapname=63600000 \ --mapname=63600001 \ --family-id=787 \ --product-id=15 \ --family-name="OSM ER 2012" \ --country-abbr="US" \ --country-name="United States" \ --region-abbr="NY" \ --region-name="New York" \ --series-name="OSM ER Test Series" \ --area-name="Capital District NY" \ --link-pois-to-ways \ --adjust-turn-headings \ --drive-on-right \ --check-roundabouts \ --check-roundabout-flares \ --add-pois-to-areas \ --location-autofill \ $1
any suggestions as to what's up?
thanks, richard
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale LibreOffice desde http://es.libreoffice.org/descarga/ LibreOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. LibreOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones.
On 11/24/12 2:48 PM, Carlos Dávila wrote:
AFAIK house numbers are not coded in mkgmap, so you can't use them. In the devices you will have to enter a fake house number in some searches though.
i see. is a house number feature likely to be added at any time in the near future? thanks, richard
On 11/24/12 2:55 PM, Richard Welty wrote:
On 11/24/12 2:48 PM, Carlos Dávila wrote:
AFAIK house numbers are not coded in mkgmap, so you can't use them. In the devices you will have to enter a fake house number in some searches though.
i see. is a house number feature likely to be added at any time in the near future?
i should add that 1) i think there is one good reason why it's really important, and 2) i am working on a project for which it's an absolute requirement. it's important because in many cities, you will see streets that are segmented. in Albany, NY, Cortland Street is in four distinct segments, and navigating from one to the next is in 2 cases hard. Cortland is not the only such street in Albany, nor is Albany unique among cities on the east coast of the US. just being able to navigate to the center of one segment with no real help selecting the segment is not useful. my specific application is providing accurate GPS maps for use by fire departments and companies responding to mutual assistance calls outside of their normal areas of responsibility. this is actually a major problem with dispatch processes in NY, but the GPS maps need house number based routing to be effective. so here is where i point out that 1) i'm an experienced java developer, and 2) i am between consulting assignments and so have some time. can i be of help? richard
On 11/24/12 2:55 PM, Richard Welty wrote:
On 11/24/12 2:48 PM, Carlos Dávila wrote:
AFAIK house numbers are not coded in mkgmap, so you can't use them. In the devices you will have to enter a fake house number in some searches though.
i see. is a house number feature likely to be added at any time in the near future?
i should add that 1) i think there is one good reason why it's really important, and 2) i am working on a project for which it's an absolute requirement.
it's important because in many cities, you will see streets that are segmented. in Albany, NY, Cortland Street is in four distinct segments, and navigating from one to the next is in 2 cases hard. Cortland is not the only such street in Albany, nor is Albany unique among cities on the east coast of the US. just being able to navigate to the center of one segment with no real help selecting the segment is not useful.
my specific application is providing accurate GPS maps for use by fire departments and companies responding to mutual assistance calls outside of their normal areas of responsibility. this is actually a major problem with dispatch processes in NY, but the GPS maps need house number based routing to be effective.
so here is where i point out that 1) i'm an experienced java developer, and 2) i am between consulting assignments and so have some time. can i be of help?
richard
AFAIK at least two tasks must be solved to make housenumber search work: 1) The format of the housenumber part within the garmin img format must be unscrambled. I think Steve has an idea how it looks like (http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q1/013549.html) 2) As Steve pointed out there must be an algorithm that associates housenumbers to nodes in roads. This sounds like a good point where you could help. Do you have some ideas how to realize that? WanMil
On 11/25/12 9:16 AM, WanMil wrote:
AFAIK at least two tasks must be solved to make housenumber search work: 1) The format of the housenumber part within the garmin img format must be unscrambled. I think Steve has an idea how it looks like (http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q1/013549.html)
2) As Steve pointed out there must be an algorithm that associates housenumbers to nodes in roads. This sounds like a good point where you could help. Do you have some ideas how to realize that?
i'll be happy to look at these, i need to check out the code first and get an idea of how it's organized. i see an eclipse .project file in svn, is eclipse the norm for mkgmap development? richard
On Sun, Nov 25, WanMil wrote:
2) As Steve pointed out there must be an algorithm that associates housenumbers to nodes in roads. This sounds like a good point where you could help. Do you have some ideas how to realize that?
I think this all comes down to calculate the shortest distance between a point (the addr:housenumber) and a line (highway=*). You can find some solutions on the net, like: http://stackoverflow.com/questions/849211/shortest-distance-between-a-point-... No we face some problems: 1) streets are complex lines 2) what is the right street? 3) what is the node for a housenumber, if it is attached to a polygone? For 2), we can match the street names, if there is addr:street given. If no street name is given, it's getting difficult. But maybe we should start with the simple cases and extend later? For 3), we can use the same algorithm as we use for placing a POI for a mulitpolygon, including entrance, etc. Don't know if anything of this is realistic doable, but I think we should start brainstorming about this, and maybe collect the ideas, problems and algorithms somewhere, so that other people can join and help. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On 11/25/12 9:51 AM, Thorsten Kukuk wrote:
On Sun, Nov 25, WanMil wrote:
2) As Steve pointed out there must be an algorithm that associates housenumbers to nodes in roads. This sounds like a good point where you could help. Do you have some ideas how to realize that? I think this all comes down to calculate the shortest distance between a point (the addr:housenumber) and a line (highway=*). You can find some solutions on the net, like: http://stackoverflow.com/questions/849211/shortest-distance-between-a-point-...
No we face some problems: 1) streets are complex lines you'd have to use the algorithm against the group of segments, but it could produce deceptive results with roads that "snake" about a bit.
driveways? in rural areas, an address may be attached to a building which is some distance away from a rural road, connected by a driveway. in these cases, we need to deliver a route to the foot of the correct driveway. will have to think about this algorithm. at least, if the driveway is in OSM, there will be an appropriate node, if we can just figure out which one it is. driveways could, though, be a solution to the snaky road problem. closest driveway leads you to the correct node on the road.
2) what is the right street? 3) what is the node for a housenumber, if it is attached to a polygone?
For 2), we can match the street names, if there is addr:street given. If no street name is given, it's getting difficult. But maybe we should start with the simple cases and extend later? yes. since i will have considerable control over the address imports for my application, i can make sure that we have a simple case. i can't imagine a US based mapper leaving the street name off if they have real address data. if they don't have full addresses for a POI, then it might be missing. but POI lookup is more likely to be done from the POI listings rather than via address lookup anyway; the omission doesn't seem critical. For 3), we can use the same algorithm as we use for placing a POI for a mulitpolygon, including entrance, etc. i don't know that algorithm, but either you can use the closest node on the polygon, or you can compute a centroid for the polygon and use that.
richard
Concerning housenumber search, as far as I know Garmin maps with cgpsmapper supports this. See for instance http://nzopengps.org/ Is the code of cgpsmapper not available and useful for mkgmap?
Am 25.11.2012 16:17, schrieb Richard Welty:
On 11/25/12 9:51 AM, Thorsten Kukuk wrote:
I think this all comes down to calculate the shortest distance between a point (the addr:housenumber) and a line (highway=*). You can find some solutions on the net, like: http://stackoverflow.com/questions/849211/shortest-distance-between-a-point-... No we face some problems: 1) streets are complex lines you'd have to use the algorithm against the group of segments, but it could produce deceptive results with roads that "snake" about a bit.
driveways? in rural areas, an address may be attached to a building which is some distance away from a rural road, connected by a driveway. in these cases, we need to deliver a route to the foot of the correct driveway. will have to think about this algorithm. at least, if the driveway is in OSM, there will be an appropriate node, if we can just figure out which one it is.
driveways could, though, be a solution to the snaky road problem. closest driveway leads you to the correct node on the road. Whats what I've learned while Operation Cowboy. In Europe this isn't really critical, because mainly buildings are next to the road. In US this is different in rural areas. There are houses in the middle of nowhere. What would a user assume? Routing ends at highway, where driveway starts or at the end of driveway? I'm mapping in Wyoming and there I've seen sometimes very long driveways [ http://mc.bbbike.org/mc/?lon=-105.10806&lat=41.83972&zoom=16&num=1&mt0=mapni... ] so I espect a routing to end of driveway.
For 3), we can use the same algorithm as we use for placing a POI for a mulitpolygon, including entrance, etc. i don't know that algorithm, but either you can use the closest node on the polygon, or you can compute a centroid for the polygon and use that. I think mkgmap has an algorithm for this. ( --add-poi-to-area )
Henning
On 11/25/12 11:21 AM, Henning Scholland wrote:
Whats what I've learned while Operation Cowboy. In Europe this isn't really critical, because mainly buildings are next to the road. In US this is different in rural areas. There are houses in the middle of nowhere. What would a user assume? Routing ends at highway, where driveway starts or at the end of driveway? I'm mapping in Wyoming and there I've seen sometimes very long driveways [ http://mc.bbbike.org/mc/?lon=-105.10806&lat=41.83972&zoom=16&num=1&mt0=mapni... ] so I espect a routing to end of driveway.
it's not just the west. here is a spot (about 1 mile from my home in upstate NY) which is a good example of the rural US: http://www.openstreetmap.org/?lat=42.61604&lon=-73.59272&zoom=17&layers=M richard
On Sun, Nov 25, WanMil wrote:
2) As Steve pointed out there must be an algorithm that associates housenumbers to nodes in roads. This sounds like a good point where you could help. Do you have some ideas how to realize that?
I think this all comes down to calculate the shortest distance between a point (the addr:housenumber) and a line (highway=*). You can find some solutions on the net, like: http://stackoverflow.com/questions/849211/shortest-distance-between-a-point-...
No we face some problems: 1) streets are complex lines 2) what is the right street? 3) what is the node for a housenumber, if it is attached to a polygone?
For 2), we can match the street names, if there is addr:street given. If no street name is given, it's getting difficult. But maybe we should start with the simple cases and extend later?
For 3), we can use the same algorithm as we use for placing a POI for a mulitpolygon, including entrance, etc.
Don't know if anything of this is realistic doable, but I think we should start brainstorming about this, and maybe collect the ideas, problems and algorithms somewhere, so that other people can join and help.
Thorsten
Good summary about the things to solve! Just my 2 cents about the development: As I told there are 2 points that have to be solved: 1) Garmin format for housenumbers 2) Housenumber => node in road In the beginning I propose to implement a *very* easy algorithm for 2) to be able to realize point 1). The algorithm could be: For each road with name=R get all nodes with addr:housenumber=* and addr:street=R. Associate those nodes with its closest point in the road. This algorithm will provide a quite bad coverage but it sounds like a good algorithm to check the garmin format implementation because it is fast and easy traceable. Anyhow Steve must have time to implement the garmin format or he must tell the list what he thinks how it works so that someone else can try an implementation. Having a working prototype we can improve the algorithm more and more (maybe also with regional variants). At this point we can also easily change how the mkgmap internal association housenumber => node is realized. Maybe we will face performance and/or memory problems. WanMil
On 25/11/12 22:10, WanMil wrote:
Anyhow Steve must have time to implement the garmin format or he must tell the list what he thinks how it works so that someone else can try an implementation.
I just thought of this today - what I would do is implement street numbers from Polish format first. Since that format doesn't require any OSM processing, we could get a known working system going independently of the osm/pbf side of things. It might even be useful to someone by itself. ..Steve
Maybe you can pick up some ideas how the NZ guys have done it? http://code.google.com/p/nzopengps/source/browse/trunk/scripts/processing_li... Steve wrote:
I just thought of this today - what I would do is implement street numbers from Polish format first. Since that format doesn't require any OSM processing, we could get a known working system going independently of the osm/pbf side of things. It might even be useful to someone by itself.
On 26/11/12 09:25, Minko wrote:
Maybe you can pick up some ideas how the NZ guys have done it? http://code.google.com/p/nzopengps/source/browse/trunk/scripts/processing_li...
It appears to use a database, rather than working directly from the osm/pbf, as has the other example I've looked at. It might be useful to get going with. And it might be good if mkgmap could use a database as its input too. ..Steve
On 11/26/12 6:19 PM, Steve Ratcliffe wrote:
On 26/11/12 09:25, Minko wrote:
Maybe you can pick up some ideas how the NZ guys have done it? http://code.google.com/p/nzopengps/source/browse/trunk/scripts/processing_li... It appears to use a database, rather than working directly from the osm/pbf, as has the other example I've looked at.
It might be useful to get going with. And it might be good if mkgmap could use a database as its input too.
it seemed to have potential value for algorithmic inspiration if nothing else. i have an enormous amount of experience with java running against database backends if that would be of use. richard
On 11/25/12 9:16 AM, WanMil wrote:
2) As Steve pointed out there must be an algorithm that associates housenumbers to nodes in roads. This sounds like a good point where you could help. Do you have some ideas how to realize that?
so to get accurate delivery to a housenumber, we'll have to add nodes when there is no suitable node already in place?
this suggests that interpreting address interpolations would be problematic. i can't help but thing that there must be an interpolation scheme available, as the old TIGER address based maps used the old TIGER interpolation data to support addresses. this isn't a deal breaker, as my aim is to import enhanced 911 address data into OSM as ODBL compatible releases of the data are made by the various GIS departments. richard
participants (7)
-
Carlos Dávila -
Henning Scholland -
Minko -
Richard Welty -
Steve Ratcliffe -
Thorsten Kukuk -
WanMil