Hi all, while looking at the relation type=associatedStreet I noticed another kind of information that is still ignored: See e.g. http://www.openstreetmap.org/relation/1518163 It contains members tagged with role=house which are not buildings but lines with a tag addr:interpolation=all and two nodes giving the range of housenumbers, nothing else. I am not yet sure how to use that info, working on it... Gerd -- View this message in context: http://gis.19327.n5.nabble.com/housenumbers-and-addr-interpolation-tp5825987... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, isn't it a direct fit for Garmin format? I don't know details, but I assume that cgpsmapper format is very straight description of internal structure of img. My understanding is that if you assign house numbers to two consecutive junctions, then GPS will interpolate addresses between these junctions. Cgpsmapper offer possibility to define different numbers for both sides of the road and settings like even/odd/both, which describe how interpolation should be computed. I guess mkgamp already has similar settings hidden somewhere in algorithms. -- Best regards, Andrzej
Hi Andrzej, yes, the img format is quite similar, but that doesn't help here. The current algo never "sees" the complete relation. I probably have to add a new hook like the POIGeneratorHook to change that. I'll look at it tomorrow. Gerd popej wrote
Hi Gerd,
isn't it a direct fit for Garmin format?
I don't know details, but I assume that cgpsmapper format is very straight description of internal structure of img. My understanding is that if you assign house numbers to two consecutive junctions, then GPS will interpolate addresses between these junctions. Cgpsmapper offer possibility to define different numbers for both sides of the road and settings like even/odd/both, which describe how interpolation should be computed. I guess mkgamp already has similar settings hidden somewhere in algorithms.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/housenumbers-and-addr-interpolation-tp5825987... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, hi Andrzej, yes, up to now mkgmap collects all elements (pois and polygons) tagged with addr:housenumber and mkgmap:street (which need to be set by the style). The elements are afterwards assigned to the nearby street with the same name. Elements more far away than 500m (?) are discarded. The street is then divided into segments and mkgmap tries to find the housenumbers at both ends and both sides of the segments. Additionally it checks if all housenumbers on one side of the segment are even/odd/both. Relations like associatedStreet and addr:interpolation were not implemented by me because the quality was very very bad on the time of my implementation. Most useful addr:interpolation lines did have a start/stop point with adequate tagging (addr:housenumber and addr:street) so there wouldn't have been any quality gain by supporting it. Now there might have been changes in the tagging quality. Although I would recommend to check that first. I strongly recommend to only support taggings how they are documented in the wiki. Otherwise mkgmap would support bad tagging which I think is not helpful at all. WanMil
Hi Gerd,
isn't it a direct fit for Garmin format?
I don't know details, but I assume that cgpsmapper format is very straight description of internal structure of img. My understanding is that if you assign house numbers to two consecutive junctions, then GPS will interpolate addresses between these junctions. Cgpsmapper offer possibility to define different numbers for both sides of the road and settings like even/odd/both, which describe how interpolation should be computed. I guess mkgamp already has similar settings hidden somewhere in algorithms.
Hi WanMil,
up to now mkgmap collects all elements (pois and polygons) tagged with addr:housenumber and mkgmap:street (which need to be set by the style). The elements are afterwards assigned to the nearby street with the same name.
Maybe you could convert a way with addr:interpolate into multiple points with single addresses and add them all to collection? Or maybe better use both ends of way and one or a few intermediate addresses?
Relations like associatedStreet and addr:interpolation were not implemented by me because the quality was very very bad on the time of my implementation.
I have filtered associatedStreet from bigger area and I have found many incomplete objects. But I hope it should be quite easy to rate object quality and discard wrong or redundant information.
I strongly recommend to only support taggings how they are documented in the wiki.
Both: associatedStreet and addr:interpolation are documented: http://wiki.openstreetmap.org/wiki/Relation:associatedStreet http://wiki.openstreetmap.org/wiki/Key:addr#Tags_for_interpolation_ways See statistics too: https://taginfo.openstreetmap.org/keys/addr:interpolation https://taginfo.openstreetmap.org/tags/type=associatedStreet -- Best regards, Andrzej
Both: associatedStreet and addr:interpolation are documented: http://wiki.openstreetmap.org/wiki/Relation:associatedStreet http://wiki.openstreetmap.org/wiki/Key:addr#Tags_for_interpolation_ways
"As long as we don't have a node or building outline for each house(number) along a way, it's also possible to use automatic number interpolation. For that, draw a way connecting the existing house numbers and mark it with the type of interpolation as shown in the picture above. Additional tags such as addr:street=* are still added to the objects with the addr:housenumber=* tag, the interpolation way only gets the addr:interpolation=* tag. " So in other words, addr:interpolation should connect two or more elements that are fully tagged with addr:housenumber and addr:street. So there is no improvement in adding an addr:interpolation handling to mkgmap. When removing the interpolation line you still have the single elements with the housenumber information. They are already converted to the Garmin format which automatically interpolates. There is one exception: In case an interpolation covers more than one street segment: ´| ========┴======= 1------------15 The interpolation 1 to 15 spans over the crossroads. The street have two segment so the current algorithm ignores the interpolation and would assign housenumber 1 to the left and 15 to the right segment. This could be the place where mkgmap might add two virtual housenumber nodes e.g. 9 and 11.
See statistics too: https://taginfo.openstreetmap.org/keys/addr:interpolation https://taginfo.openstreetmap.org/tags/type=associatedStreet
Hi WanMil, (did not read this yesterday) I agree in most points, but maybe the information that is given with the addr:interpolation tag should also be used? The stats in taginfo say that most of them are odd/even, so we can ignore them. But what about "all" ? Do you have time to code the interpretation of the addr:interpolation tag? I don't have an idea how to use it besides simply adding all housenumbers, but that seems a bit memory costly. Gerd
Date: Mon, 1 Dec 2014 22:28:50 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] housenumbers and addr:interpolation
Both: associatedStreet and addr:interpolation are documented: http://wiki.openstreetmap.org/wiki/Relation:associatedStreet http://wiki.openstreetmap.org/wiki/Key:addr#Tags_for_interpolation_ways
"As long as we don't have a node or building outline for each house(number) along a way, it's also possible to use automatic number interpolation. For that, draw a way connecting the existing house numbers and mark it with the type of interpolation as shown in the picture above. Additional tags such as addr:street=* are still added to the objects with the addr:housenumber=* tag, the interpolation way only gets the addr:interpolation=* tag. "
So in other words, addr:interpolation should connect two or more elements that are fully tagged with addr:housenumber and addr:street. So there is no improvement in adding an addr:interpolation handling to mkgmap. When removing the interpolation line you still have the single elements with the housenumber information. They are already converted to the Garmin format which automatically interpolates.
There is one exception: In case an interpolation covers more than one street segment: ´| ========┴======= 1------------15
The interpolation 1 to 15 spans over the crossroads. The street have two segment so the current algorithm ignores the interpolation and would assign housenumber 1 to the left and 15 to the right segment. This could be the place where mkgmap might add two virtual housenumber nodes e.g. 9 and 11.
See statistics too: https://taginfo.openstreetmap.org/keys/addr:interpolation https://taginfo.openstreetmap.org/tags/type=associatedStreet
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd
I agree in most points, but maybe the information that is given with the addr:interpolation tag should also be used? The stats in taginfo say that most of them are odd/even, so we can ignore them. But what about "all" ?
I agree that addr:interpolation should be used when present. If you only have two numbers at each end of the interpolation range you need to know if the intermediate numbers are odd, even or both. If the value is something other than odd,even or all then the mapper was either trying to do something more complex or was just confused, in which case I would ignore the interpolation. ..Steve
Hi Steve, I found another tag that we don't use: addr:place This is used frequently, but I don't know if the img format supports it? Gerd Steve Ratcliffe wrote
Hi Gerd
I agree in most points, but maybe the information that is given with the addr:interpolation tag should also be used? The stats in taginfo say that most of them are odd/even, so we can ignore them. But what about "all" ?
I agree that addr:interpolation should be used when present. If you only have two numbers at each end of the interpolation range you need to know if the intermediate numbers are odd, even or both. If the value is something other than odd,even or all then the mapper was either trying to do something more complex or was just confused, in which case I would ignore the interpolation.
..Steve _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/housenumbers-and-addr-interpolation-tp5825987... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd,
I found another tag that we don't use: addr:place
This is used frequently, but I don't know if the img format supports it?
addr:place is used instead of addr:street - some addresses don't contain street name but name of village instead. I don't think there is possibility to add points without a road to address search. Often used circumvention for this problem is to give place name to nameless roads in nearby area. Then you can add house numbers to roads and get these addresses in standard address search. City Navigator maps use this solution. Other possibility is to create short artificial road (like 10m) at the point position and add to it place name and house number. This road doesn't have to be routable, only available in search index. This solution is used for transparent maps of addresses. -- Best regards, Andrzej
Hi WanMil, I agree that we should not support undocumented tagging. The question for me is whether the combination of type=associatedStreet and members with role=house whch have the addr:interpolation=* tag is documented. I fear the wiki is not clear about this. Regarding the normal use of addr:interpolation: I'll add some code to check if the evaluation is useful. I think it will improve results when the nodes of the way have no addr:street tag. The tag value in the addr:interpolation would also be interesting when it is a number, e.g. a value 3 in combination with housenumbers 2 and 20 mean 2,5,8,11,14,17,20, while a value 2 means even. I have no idea why someone would use that with numbers like 18, so maybe all the data using numbers is wrong. Gerd WanMil wrote
Hi Gerd, hi Andrzej,
yes, up to now mkgmap collects all elements (pois and polygons) tagged with addr:housenumber and mkgmap:street (which need to be set by the style). The elements are afterwards assigned to the nearby street with the same name. Elements more far away than 500m (?) are discarded. The street is then divided into segments and mkgmap tries to find the housenumbers at both ends and both sides of the segments. Additionally it checks if all housenumbers on one side of the segment are even/odd/both.
Relations like associatedStreet and addr:interpolation were not implemented by me because the quality was very very bad on the time of my implementation. Most useful addr:interpolation lines did have a start/stop point with adequate tagging (addr:housenumber and addr:street) so there wouldn't have been any quality gain by supporting it.
Now there might have been changes in the tagging quality. Although I would recommend to check that first. I strongly recommend to only support taggings how they are documented in the wiki. Otherwise mkgmap would support bad tagging which I think is not helpful at all.
WanMil
Hi Gerd,
isn't it a direct fit for Garmin format?
I don't know details, but I assume that cgpsmapper format is very straight description of internal structure of img. My understanding is that if you assign house numbers to two consecutive junctions, then GPS will interpolate addresses between these junctions. Cgpsmapper offer possibility to define different numbers for both sides of the road and settings like even/odd/both, which describe how interpolation should be computed. I guess mkgamp already has similar settings hidden somewhere in algorithms.
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/housenumbers-and-addr-interpolation-tp5825987... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (5)
-
Andrzej Popowski -
Gerd Petermann -
GerdP
-
Steve Ratcliffe -
WanMil