Re: [OSM-talk] Skip geographical (redundant) address tags
Lennard wrote: On 6-5-2011 20:44, Pierre-Alain Dorange wrote: I could not really help you (i don't know your region, but as i can see (using JOSM) there is no admin relation in this area, so few clues to help nomatim to find location. The entire Netherlands is covered by admin relations. Of course, occasionally, these get broken. Also, not every admin_level=10 is there yet. Up to z8 is complete, barring broken data. The municipality is here: http://www.openstreetmap.org/browse/relation/188858 However, we don't have an admin_level=10 relation for the town called Helden, on account of the municipality not giving us their boundaries yet. There's another mapper tracing these from official documents (less accurate than receiving the original geo data, but alas), but he doesn't seem to have done this yet. I have added admin_level=10 with data from 6pp and own knowledge. It's probably a bit crude compared with original sources but I think it is correct. It still does not explain the zipcode though. Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
Maarten Deen md...@xs4all.nl wrote: I was unaware I still had the country wrong for some places, I thought I'd found and fixed all these. Recalculating the street now produces the right result (as you can see if you re-do your search) so I'll do another forced update and try and get the last of these problems fixed. I now get two results, one is still Jacob van Marisring, België (maybe just a residual result?), the other is now Jacob van Marisring, Peel en Maas, Limburg, 5988KJ, Nederland. While the location arrow is correct, the name is not. It displays the municipality and not the town (Peel en Maas should be Helden) which I think is caused by the missing admin_level=10 boundaries. It also displays the wrong zipcode. 5988KJ is the zipcode for Willem van Heukelomstraat [1], the correct zipcode would be 5988KG. Where do you get the zipcode from? I have a few houses tagged with addr: keys, all of which I believe to have correct addr:postcode and addr:street. I could not really help you (i don't know your region, but as i can see (using JOSM) there is no admin relation in this area, so few clues to help nomatim to find location. An admin relation groups all boundary ways into a single object that form a closed area. From that it's very easy for nominatim to find exact adresses. For example in my area (Cognac, France) adresses are correct aven on borders. http://open.mapquestapi.com/nominatim/v1/search.php?q=rue+du+buisson+mor eauviewbox=5.98%2C51.33%2C6%2C51.31 Their is 2 results (because just write the street name without the city) : one in Corea and the other in France. the second one (the good one of course) has all the correct admin info : Champ de Foire (the suburb), Cognac (city defined by a relation), Communauté de Communes de Cognac (city group defined by a relation), Charentes (the county, defined by a relation), Poitou-Charentes (region, defined by a relation) and of course France and the zip code. It just add a strange Les Ormeaux (a place located 150 km away) OpenMapQuest API let you examine the different areas and objects : http://open.mapquestapi.com/nominatim/v1/details.php?place_id=49125331 For example, Cognac city defined by an admin relation is very precise for Nomatim : http://open.mapquestapi.com/nominatim/v1/details.php?place_id=79399357 The suburb, defined by a node place is approximative and nomatim use an estimation : http://open.mapquestapi.com/nominatim/v1/details.php?place_id=79399357 More precision, as Cognac street has adresses on building you can even located a precise adress in a street : 28 buisson moreau, cognac return the exact place : http://open.mapquestapi.com/nominatim/v1/details.php?place_id=8938235 If we examine you request in Nominatim's OpenMapquest we got : http://open.mapquestapi.com/nominatim/v1/details.php?place_id=14534301 It show that Peel en Maas is an admin relation http://open.mapquestapi.com/nominatim/v1/details.php?place_id=79449231 It's topologicaly right, the street is in this area. and that Helden (rejected by algo) is just a place village (so Nomatim has to estimate the area with a baloon) : http://open.mapquestapi.com/nominatim/v1/details.php?place_id=241938 And unfortunnally the ballon-estimation place the street half in, half ou the ballon, so finilly Nomatim decide to reject... A boundary relation will solve the problem. Nominatim used admin relation, it's far more precise than any other method. -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
On 6-5-2011 20:44, Pierre-Alain Dorange wrote: I could not really help you (i don't know your region, but as i can see (using JOSM) there is no admin relation in this area, so few clues to help nomatim to find location. The entire Netherlands is covered by admin relations. Of course, occasionally, these get broken. Also, not every admin_level=10 is there yet. Up to z8 is complete, barring broken data. The municipality is here: http://www.openstreetmap.org/browse/relation/188858 However, we don't have an admin_level=10 relation for the town called Helden, on account of the municipality not giving us their boundaries yet. There's another mapper tracing these from official documents (less accurate than receiving the original geo data, but alas), but he doesn't seem to have done this yet. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
Lennard l...@xs4all.nl wrote: I could not really help you (i don't know your region, but as i can see (using JOSM) there is no admin relation in this area, so few clues to help nomatim to find location. The entire Netherlands is covered by admin relations. Of course, occasionally, these get broken. Also, not every admin_level=10 is there yet. Up to z8 is complete, barring broken data. The municipality is here: http://www.openstreetmap.org/browse/relation/188858 OK, that's the admin relation Nominatim used to link the request street to Peel en Maas. However, we don't have an admin_level=10 relation for the town called Helden, Yes just a node place=village that Nominatim could nt link to the requested street. on account of the municipality not giving us their boundaries yet. I hope you could get them soon. In france, not all town has it's boundary but some regions are quite complete. We used admin_level=8 for municipality and level=10 is almost not used (not in my region) and according to the wiki must be used for suburb‹ in big town. -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
On 6-5-2011 22:46, Pierre-Alain Dorange wrote: OK, that's the admin relation Nominatim used to link the request street to Peel en Maas. Correct. It's correct, given the data. The real question is why it was also categorised as being in Belgium. I hope you could get them soon. We'd have to send another FOIA request. We used admin_level=8 for municipality and level=10 is almost not used (not in my region) and according to the wiki must be used for suburb‹ in big town. The levels vary by country. In NL level 10 is used for official subparts of municipalities. Even those subparts can consist of more than one dwelling, to make it even more confusing. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
Lennard l...@xs4all.nl wrote: OK, that's the admin relation Nominatim used to link the request street to Peel en Maas. Correct. It's correct, given the data. The real question is why it was also categorised as being in Belgium. Following MapQuest Nominatim link (for Belgium response) : http://open.mapquestapi.com/nominatim/v1/details.php?place_id=14582407 It's a dead end... Belgique is indicate but without any ref and nomore link... just the indcation place=county, polygon. It llok like an error or perhaps an olf object belgique that was removed... If we look for belgique with nominatim we found 2 valid answers : one for a node 'place=country (would not help Nominatim) and the other the boundary relation. http://open.mapquestapi.com/nominatim/v1/details.php?place_id=4492935 http://open.mapquestapi.com/nominatim/v1/details.php?place_id=79371128 -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
Maarten Deen md...@xs4all.nl wrote: Nominatim use them (boundariy relations) efficiently. The lookup may be efficient, it is frequently wrong and again dependent of correct and complete admin_levels. Currently it places every street where I live (in the Netherlands) in Belgium and does not specify a town with it. Looking for Jacob van Marisring returns Jacob van Marisring, België 51.32,51.32 14558705 (Residential). Searching for Jacob van Marisring, Helden even returns an error. On contrary, in many region in France (and better in my own region, Charente) Nominatim is accurate and use very well relations, it works fine and is quickly updated. For example i rencently add a new admin boundary (city regroupment = communauté de communes in France) and nominatim indicate it after 2-3 days. I do not notice any major addresses errors in my area. -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
The lookup may be efficient, it is frequently wrong and again dependent of correct and complete admin_levels. Currently it places every street where I live (in the Netherlands) in Belgium and does not specify a town with it. Looking for Jacob van Marisring returns Jacob van Marisring, België 51.32,51.32 14558705 (Residential). Searching for Jacob van Marisring, Helden even returns an error. I was unaware I still had the country wrong for some places, I thought I'd found and fixed all these. Recalculating the street now produces the right result (as you can see if you re-do your search) so I'll do another forced update and try and get the last of these problems fixed. Also note that in the FAQ page of nominatim, the suggestion is done to fix errors by adding addr: or is_in: tags. I feel you are rather miss-quoting the FAQ: If a street or higher level feature (city, town, county, etc.) has the wrong address you can either add a is_in tag to provide an explicit address or, *preferably, draw a polygon or create an admin boundary relation for the feature that should contain it*. note the second half of the sentence! -- Brian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
Felix Hartmann extremecar...@gmail.com wrote: Nope, it makes sense all the time. Cause boundaries really are not ment for deducting information onto what's inside. This really slows down any kind of processing (much much more than having data duplicated which only takes up a bit more disk space). Nominatim use them (boundariy relations) efficiently. Adding extra data on every address is not a bit more space it can be huge when you add addresses on every house of a city. And that also really slow down things. -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
On Wed, 4 May 2011 08:07:07 +0200, pdora...@mac.com (Pierre-Alain Dorange) wrote: Felix Hartmann extremecar...@gmail.com wrote: Nope, it makes sense all the time. Cause boundaries really are not ment for deducting information onto what's inside. This really slows down any kind of processing (much much more than having data duplicated which only takes up a bit more disk space). Nominatim use them (boundariy relations) efficiently. The lookup may be efficient, it is frequently wrong and again dependent of correct and complete admin_levels. Currently it places every street where I live (in the Netherlands) in Belgium and does not specify a town with it. Looking for Jacob van Marisring returns Jacob van Marisring, België 51.32,51.32 14558705 (Residential). Searching for Jacob van Marisring, Helden even returns an error. Also note that in the FAQ page of nominatim, the suggestion is done to fix errors by adding addr: or is_in: tags. Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
2011/5/4 Maarten Deen md...@xs4all.nl: On Wed, 4 May 2011 08:07:07 +0200, pdora...@mac.com (Pierre-Alain Dorange) wrote: Felix Hartmann extremecar...@gmail.com wrote: Nope, it makes sense all the time. Cause boundaries really are not ment for deducting information onto what's inside. This really slows down any kind of processing (much much more than having data duplicated which only takes up a bit more disk space). Nominatim use them (boundariy relations) efficiently. The lookup may be efficient, it is frequently wrong and again dependent of correct and complete admin_levels. Currently it places every street where I live (in the Netherlands) in Belgium and does not specify a town with it. Looking for Jacob van Marisring returns Jacob van Marisring, België 51.32,51.32 14558705 (Residential). Searching for Jacob van Marisring, Helden even returns an error. This correct - general side-effect of removal redundancy is that you are also creating more single points of failures. In this terms having millions copies of addr:country=DE is better than to have just one (implicit) relation. Regarding user interface: I would add quick street selector feature to JOSM (and other editors) - when you open PresetAnnotationsAddress screen, then instead of text field it would have buttons to select quickly up to 5 nearest streetnames. I would prefer that it would create/update relation for this, of course it could also just fill tag value. It would make entering address very easy, also for relations. -- Jaak ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
On 5/4/2011 7:58 AM, Jaak Laineste wrote: Regarding user interface: I would add quick street selector feature to JOSM (and other editors) - when you open PresetAnnotationsAddress screen, then instead of text field it would have buttons to select quickly up to 5 nearest streetnames. I would prefer that it would create/update relation for this, of course it could also just fill tag value. It would make entering address very easy, also for relations. JOSM has this plugin, minus the 5 nearest street names. http://wiki.openstreetmap.org/wiki/JOSM/Plugins/AddrInterpolation (I'm personally a non-relation type, as I don't think relations add value to map data in this case, but only add complexity). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
2011/5/4 Jaak Laineste jaak.laine...@gmail.com: Regarding user interface: I would add quick street selector feature to JOSM (and other editors) a workaround to improve usability would be to enable autocompletion of addr:street with the values of the name-keys of the highways. cheers, Martin https://josm.openstreetmap.de/ticket/6306 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Skip geographical (redundant) address tags
Hello, It looks like trivial suggestion, but could not find any past discussions with quick search. Is there good reason to add addr:country, addr:county, addr:city and other regional tags to all the address tags, if OSM database already has administrative regions for given area? These admin areas already create implicit relation, which can be used in any application to add city,country,district,state and other regions. So buildings would have only addr:street, addr:housenumber (and possibly house:housename and addr:full tags). Depending on country, addr:postcode could be geographical also. -- Jaak ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
On 3 May 2011, at 08:57, Jaak Laineste wrote: Hello, It looks like trivial suggestion, but could not find any past discussions with quick search. Is there good reason to add addr:country, addr:county, addr:city and other regional tags to all the address tags, if OSM database already has administrative regions for given area? These admin areas already create implicit relation, which can be used in any application to add city,country,district,state and other regions. So buildings would have only addr:street, addr:housenumber (and possibly house:housename and addr:full tags). Depending on country, addr:postcode could be geographical also. Searching a database for a way that surrounds a potentially enormous area (certainly enormous in the case of country) when you want to find out what city/country/... is this in is *far* less efficient than simply looking at the tags. Plus, Addresses are not always as straightforward as you make out, it's not possible to tell which administrative areas should be included in an address by simply looking at which ones happen to encompass the building. Bob ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
Jaak Laineste jaak.laineste at gmail.com writes: Is there good reason to add addr:country, addr:county, addr:city and other regional tags to all the address tags, if OSM database already has administrative regions for given area? I don't think so, except in cases where the postal regions are different from the administrative regions - but even there, the right answer would be to add areas for postal regions. In many countries, if a postal code is provided then the county and city are not needed for postal delivery, although they may still be included in long form addresses for humans (rather than mail sorters) to get an idea of where it is. It's my practice to tag addr:housenumber, addr:street and postal_code. The rest is implicit from the location on the map. Nominatim, for example, will work out what region a point is in. (It doesn't always do a good job, but the way to fix that is to improve the region areas on the map, not add redundant addr or is_in tags to every object.) That said, if you're mapping an area for the first time and you know that a house is 'in' a certain region, but not the exact boundary of that region, feel free to tag it on the house itself. It can always be improved later. -- Ed Avis e...@waniasset.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
Jaak Laineste wrote: Is there good reason to add addr:country, addr:county, addr:city and other regional tags to all the address tags, if OSM database already has administrative regions for given area? I can't speak for the other tags, but addr:city is not the same as is_in:city. I have an Orlando mailing address but am far from Orlando city limits. -- View this message in context: http://gis.638310.n2.nabble.com/Skip-geographical-redundant-address-tags-tp6326481p6326880.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
Jaak Laineste jaak.laineste at gmail.com writes: Is there good reason to add addr:country, addr:county, addr:city and other regional tags to all the address tags, if OSM database already has administrative regions for given area? I think addr:country can be identified by existing borders, but I don't know how much effort this would cause. If you look at only one node than you will have to find the country borders for that node. But where are they? Yes there is a (are there more) service in that will give you this, but that requires more effort than downloading one node. As for addr:city, you can not get this from administrative regions in the Netherlands. There is no complete admin_level=10 boundary in place. And I'm certain it also is not complete in my neighouring countries Germany and Belgium, if these boundaries exist there at all. I haven't found them (but I only glanced at some areas). Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
2011/5/3 Jo winfi...@gmail.com: What I do to avoid most redundancy, is to create an associatedStreet relation. ... I add more than one street to them though, even if JOSM complains about that. it is not just JOSM complaining about this, it is against the spec: Members Way/nodeRoleRecurrence Comment Way street one The associated street Node Area house one or more One or more house numbers (use house in tagging but in parsing also allow: addr:houselink, address ) cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
On 03.05.2011 10:09, Thomas Davie wrote: On 3 May 2011, at 08:57, Jaak Laineste wrote: Hello, It looks like trivial suggestion, but could not find any past discussions with quick search. Is there good reason to add addr:country, addr:county, addr:city and other regional tags to all the address tags, if OSM database already has administrative regions for given area? These admin areas already create implicit relation, which can be used in any application to add city,country,district,state and other regions. So buildings would have only addr:street, addr:housenumber (and possibly house:housename and addr:full tags). Depending on country, addr:postcode could be geographical also. Searching a database for a way that surrounds a potentially enormous area (certainly enormous in the case of country) when you want to find out what city/country/... is this in is *far* less efficient than simply looking at the tags. Plus, Addresses are not always as straightforward as you make out, it's not possible to tell which administrative areas should be included in an address by simply looking at which ones happen to encompass the building. Bob ___ +1 Look at all current implementations. If the address is not tagged completly (country, state, city, street) then programs are lost, and boundaries are too often wrong or incomplete or if someone deletes them accidentally (or renames them slightly) all data inside the boundary wouldn't have an address anymore. Plus it takes a lot of computation time, to put boundary information onto objects inside. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
The very first I did, I did it according to 'spec': http://www.openstreetmap.org/browse/changeset/7595148 The result is a ridiculous amount of 4 relations for a street of less than 1,5 km in length. Some of which only contain one house. And each of them containing redundant name, addr:city, addr:postcode and addr:country tags. Hence my disagreement with the spec. I did realise that JOSM probably had a reason to complain about it, ofc. Another problem/argument is that when streets are split, there will be 2 or more street segments in those relations anyway. Cheers, Polyglot 2011/5/3 M∡rtin Koppenhoefer dieterdre...@gmail.com 2011/5/3 Jo winfi...@gmail.com: What I do to avoid most redundancy, is to create an associatedStreet relation. ... I add more than one street to them though, even if JOSM complains about that. it is not just JOSM complaining about this, it is against the spec: Members Way/nodeRoleRecurrence Comment Way street one The associated street Node Area house one or more One or more house numbers (use house in tagging but in parsing also allow: addr:houselink, address ) cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
2011/5/3 Jo winfi...@gmail.com: The very first I did, I did it according to 'spec': http://www.openstreetmap.org/browse/changeset/7595148 The result is a ridiculous amount of 4 relations for a street of less than 1,5 km in length. Some of which only contain one house. And each of them containing redundant name, addr:city, addr:postcode and addr:country tags. Yes, I know. In your case (just one house) the relation indeed seems to be far less adequate in respect to simple tags. Relations add a complexity that is mostly not desirable IMHO for cases like housenumbers. The easier it is to enter (and maintain) them, the more we will get. I suggest to put the information to nodes/polygons for this reason (and for stability), even if it seems to be a less elegant (more redundant) approach from a computer science perspective. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
On Tue, May 3, 2011 at 2:22 PM, Felix Hartmann extremecar...@gmail.comwrote: +1 boundaries are too often wrong or incomplete or if someone deletes them accidentally (or renames them slightly) again the is_in discussion All these arguments above are also valid when you put the full address tags. It's always a good practice to avoid duplicated data in a database. It makes only sense if the address cannot be deduced from the boundaries (like in US, it seems). Don't forget the fundamentals : OSM is a geospatial database containing geospatial data. If you are a consumer, use a database server with geospatial functions like postGIS (otherwise we don't need coordinates in nodes). It's true that it requires some skills and learning curves and lazy programmers can always expect that contributors will do the job for them... Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
Hmm, I'm convinced the associatedStreet relation is the most elegant way to solve the redundancy problem. The biggest issue with it is the one street per relation limitation, which I don't understand where it comes from. So, as far as I'm concerned, it'd be better to redefine it. Polyglot 2011/5/3 M∡rtin Koppenhoefer dieterdre...@gmail.com 2011/5/3 Jo winfi...@gmail.com: The very first I did, I did it according to 'spec': http://www.openstreetmap.org/browse/changeset/7595148 The result is a ridiculous amount of 4 relations for a street of less than 1,5 km in length. Some of which only contain one house. And each of them containing redundant name, addr:city, addr:postcode and addr:country tags. Yes, I know. In your case (just one house) the relation indeed seems to be far less adequate in respect to simple tags. Relations add a complexity that is mostly not desirable IMHO for cases like housenumbers. The easier it is to enter (and maintain) them, the more we will get. I suggest to put the information to nodes/polygons for this reason (and for stability), even if it seems to be a less elegant (more redundant) approach from a computer science perspective. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
Hi, On 05/03/2011 03:12 PM, Jo wrote: Hmm, I'm convinced the associatedStreet relation is the most elegant way to solve the redundancy problem. The biggest issue with it is the one street per relation limitation, which I don't understand where it comes from. So, as far as I'm concerned, it'd be better to redefine it. Done. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
Jo wrote: Hmm, I'm convinced the associatedStreet relation is the most elegant way to solve the redundancy problem. There is no redundancy problem. No, really. There is nothing fundamentally wrong with redundancy. Redundancy per se doesn't cause any harm to our database. Looking at taginfo and trying to bring down all numbers in the count column to 1 is /not/ an appropriate strategy for improving our data. As for house numbers: They are an ubiquitous feature. They should therefore be easy to tag. A good way to achieve that, in my opinion, is: 1) Add the tags for data that you find out on the ground by standing in front of a house directly to that house. In most places, this includes the housenumber/-name and street name. 2) Add stuff that you get from official documents or other large-scale sources as boundaries - e.g. postal city boundaries, postcodes and country borders. There is no reason for a building to be part of a relation just because it has an address. It makes things more complicated than they need to be. -- Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
On 3 May 2011 15:03:07 +0200, M?rtin Koppenhoefer dieterdre...@gmail.com wrote: Yes, I know. In your case (just one house) the relation indeed seems to be far less adequate in respect to simple tags. Relations add a complexity that is mostly not desirable IMHO for cases like housenumbers. The easier it is to enter (and maintain) them, the more we will get. I suggest to put the information to nodes/polygons for this reason (and for stability), even if it seems to be a less elegant (more redundant) approach from a computer science perspective. i played with associatedStreet relations a little. in a world where relations are a touch fragile due to underdeveloped support in the editors, associatedStreet is one of the most fragile. we have a thicket of address related things (addr:interpolation ways, associatedStreet, etc.) which have been put together in a somewhat scattershot way over time. the current system doesn't quite hang together, some elements are easy to break by accident, and some things that would be nice to be able to do aren't really possible (e.g., including a building outline with an address in an interpolation way.) if associatedStreet were better supported, it could be a method for hooking postal codes to houses in the US. in some cases, you'd need different associatedStreet relations for the two sides of the street as the sides are on routes served by different post offices. richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
Felix Hartmann extremecarver at gmail.com writes: Cause boundaries really are not ment for deducting information onto what's inside. This really slows down any kind of processing (much much more than having data duplicated which only takes up a bit more disk space). It's one thing to say that to speed up and simplify processing, there should be duplicated data. Quite another to say that every contributor, on every object that has an address, should manually add several redundant tags. Let's tag the information that is needed, but not restate the same thing in several different ways. Then if some different presentation of that info is needed, this can be done in a separate post-processing step by a computer, not by people. -- Ed Avis e...@waniasset.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
2011/5/3 Ed Avis e...@waniasset.com: It's one thing to say that to speed up and simplify processing, there should be duplicated data. Quite another to say that every contributor, on every object that has an address, should manually add several redundant tags. Let's tag the information that is needed, but not restate the same thing in several different ways. Then if some different presentation of that info is needed, this can be done in a separate post-processing step by a computer, not by people. You seem to imply that relations are faster / less manual work requiring when entering addresses manually with one of the OSM editors, but from my own experience they require at least the same (manual) work, if not more. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
On Tue, May 3, 2011 at 3:50 PM, Felix Hartmann extremecar...@gmail.comwrote: Cause boundaries really are not ment for deducting information onto what's inside. I don't know what to say against that Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
On 3 May 2011 15:53, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: You seem to imply that relations are faster / less manual work requiring when entering addresses manually with one of the OSM editors, but from my own experience they require at least the same (manual) work, if not more. +1 It couldn't be easier (in JOSM at least) to select a bunch of buildings and add the tags once. If you use a relation you must create it and add the members + tags to it so it is hard to see how that can ever be easier for the mapper which is generally what OSM is all about. Kevin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
Select some street parts, building outlines and nodes. Press the button to create a new relation and add them. Then add the properties to the relation. That really doesn't take longer than adding those properties directly to the elements themselves. Of course, I always have the relation overview window opened. Adding the roles is an extra step, but it's not a great loss if you would omit them and I wouldn't be surprised if somebody would add a feature to JOSM which assigns those roles automatically. Thanks Martin for changing the spec! Polyglot 2011/5/3 Kevin Peat ke...@kevinpeat.com On 3 May 2011 15:53, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: You seem to imply that relations are faster / less manual work requiring when entering addresses manually with one of the OSM editors, but from my own experience they require at least the same (manual) work, if not more. +1 It couldn't be easier (in JOSM at least) to select a bunch of buildings and add the tags once. If you use a relation you must create it and add the members + tags to it so it is hard to see how that can ever be easier for the mapper which is generally what OSM is all about. Kevin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
2011/5/3 M∡rtin Koppenhoefer dieterdre...@gmail.com: You seem to imply that relations are faster / less manual work requiring when entering addresses manually with one of the OSM editors, but from my own experience they require at least the same (manual) work, if not more. Creating relation could be same, or even more extra work, this is correct (but fixable in editor level). Point of avoiding redundancy (normalization) is to make maintenance easier in long run. How much manual work do you need to do if any of the underlying object is modified: street names change now and then, sometimes whole administrative system is reformed and even Europe has countries added or merged every decade. OSM database is more or less fully topologically clean (in geometry terms) and this is something what I really admire from my GIS background. Any duplicate node is error. It would make sense to follow same pattern for tags also: invalidate duplicate tag values. At least in long run. With implicit (polygon-derived) spatial relations there is no need for enduser to maintain most of the the relations: just make sure that the region polygon is complete. With explicit relation you can always override spatial relations, this would enable to cover also the city address outside of city polygon case. -- Jaak ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
2011/5/3 Jaak Laineste jaak.laine...@gmail.com: 2011/5/3 M∡rtin Koppenhoefer dieterdre...@gmail.com: Creating relation could be same, or even more extra work, this is correct (but fixable in editor level). actually it will (with explicit numbers without interpolation) not be possible at the editor level to make it less work for the relation, you will always have the relation as additional work (and you will have to enter the numbers manually, while I agree that there could be a minor improvement for pasting: https://josm.openstreetmap.de/ticket/6300 ) Point of avoiding redundancy (normalization) is to make maintenance easier in long run. How much manual work do you need to do if any of the underlying object is modified: street names change now and then, sometimes whole administrative system is reformed and even Europe has countries added or merged every decade. performing a search in JOSM you can also quite easily change lots of objects the same time. I am not totally opposing relations, they are there and you can use them if you want, it is just that most mappers don't use them (me included) for housenumbers, because it makes mapping more complicated without (IMHO) a real benefit, and it is definitely more complex (bad for less experienced mappers). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
M∡rtin Koppenhoefer dieterdreist at gmail.com writes: Let's tag the information that is needed, but not restate the same thing in several different ways. Then if some different presentation of that info is needed, this can be done in a separate post-processing step by a computer, not by people. You seem to imply that relations are faster / less manual work requiring when entering addresses manually with one of the OSM editors, but from my own experience they require at least the same (manual) work, if not more. Sorry if I wasn't clear, I was not talking about the use of relations, but rather the idea of tagging separate addr:county, addr:region etc on every individual object that has an address. (Perhaps that wasn't what the question was about, in which case I apologize.) -- Ed Avis e...@waniasset.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
Le 03/05/2011 16:54, Pieren a écrit : On Tue, May 3, 2011 at 3:50 PM, Felix Hartmann extremecar...@gmail.com mailto:extremecar...@gmail.com wrote: Cause boundaries really are not ment for deducting information onto what's inside. I don't know what to say against that Pieren Maybe boundaries are in the database for the renderers only ;-) Seriously... I can reply. Don't forget the fundamentals : OSM is a geospatial database containing geospatial data. If you are a consumer, use a database server with geospatial functions like postGIS (otherwise we don't need coordinates in nodes). It's true that it requires some skills and learning curves and lazy programmers can always expect that contributors will do the job for them... I'm using boundaries for computing localisation of things. I never have studied compuning. But i'm able to manage a postGIS database, to write queries with spatial functions with jointures, and to get some good results. It is not so hard. And somebody making requests with where clauses such as WHERE addr:country IS IN (...) is probably able to make a jointure. IMHO addr:stuff may be necessary in the way that addr:stuff is not exactly geolocalisation and can differ from ST_WITHIN results. But it is optionnal for only such cases. -- FrViPofm ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
