Re: [Tagging] Feature Proposal - RFC - addrN:*
2015-02-25 20:31 GMT+01:00 Swen Wacker swen.wac...@gmail.com: 2015-02-25 15:57 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: thank you for these references. I have noticed that all of them reference the BauGB §126, which seems to confirm that this is the legal basis for the numbering Are you kidding me? :-) 1. Neither http://www.rosenheim.de/uploads/media/631f.pdf nor http://www.bad-doberan.de/uploads/media/Hausnummernsatzung.pdf reference to BBauG. And there a lot of more. 2. Referencing to BBauG is meaningless, because every local law (Satzung) needs a landesrechtliche legislative http://www.dict.cc/englisch-deutsch/legislative.html basis. OK, still I have found sentences like soweit nicht bundesrechtliche Vorschriften bestehen. http://www.gesetze-bayern.de/jportal/portal/page/bsbayprod.psml?doc.id=jlr-StrWGBYpArt52showdoccase=1paramfromHL=true We can conclude that (in Germany) it depends only on local law. +1, which then defines either the plot or the indivually used buildings (or a subset of them with particular usage) as entity to be refered to by numbers. We can conclude, that D.h., die Hausnummern beziehen sich in Deutschland grundsätzlich auf Grundstücke http://wiki.openstreetmap.org/wiki/DE:Karlsruhe_Schema#Rechtliche_Situation lacks any legal meaning. thank you for pointing this out, IANAL, and have just tried to collect relevant information about this. I have now amended the German wiki and invite you to review this paragraph. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
2015-01-23 8:55 GMT+01:00 Swen Wacker swen.wac...@gmail.com: 2015-01-22 19:44 GMT+01:00 fly lowfligh...@googlemail.com: In Germany the address always belongs to the plot and not to the building and they are assigned in advance. This is not correct. The decision is up to the local government. In most local Hausnummer-Satzung (by-law about housenumber) that I've looked at there is a preference for buildings. German-speaking might look huere: http://forum.openstreetmap.org/viewtopic.php?pid=472337#p472337 If you look for Hausnummernsatzung it is clear you'll find likely building related stuff ;-) Have a look for Grundstücksnummerierung to find plot related information. There is national law (BauGB) that clearly states that the basis for all numbering is the plot (§126): (3) Der Eigentümer hat sein Grundstück mit der von der Gemeinde festgesetzten Nummer zu versehen. Im Übrigen gelten die landesrechtlichen Vorschriften. The lower admin entities (Land and Gemeinde) can and typically will have regulation how to reduce ambiguities (e.g. numbering of buildings, staircases, entrances, etc. if needed), and often details about shape, size and illumination of the numbers and where to put them exactly and how the system is working (consecutive numbering or even / odd numbers per street side, etc.). E.g. the Nummerierungsverordnung Berlin: http://www.stadtentwicklung.berlin.de/service/gesetzestexte/de/download/geoinformation/Vorschriftensammlung/7_1.pdf In the case of Baden-Württemberg, there are no regulations on Landes-level concerning housenumbers (AFAIK), but the municipalities have their own laws (Gemeindesatzung). E.g. this is the regulation that states that in Karlsruhe you have to put housenumbers on your _plot_, if it is used for residential or commercial purposes: http://web1.karlsruhe.de/Stadt/Stadtrecht/s-6-1-3.php I have not yet found any text that doesn't state that the plot is the main unit for numbering (and I doubt it exists, because it would conflict with federal law). Clearly, if there are numbers for several entrances (and often there are), you should consider mapping them there. Maybe our current scheme is not sufficient for mapping all those subtleties. I could imagine having 2 entities: an area which has a certain address, and an entrance node by which you can access this area. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
2015-02-25 15:09 GMT+01:00 Swen Wacker swen.wac...@gmail.com: I have not yet found any text that doesn't state that the plot is the main unit for numbering http://www.rosenheim.de/uploads/media/631f.pdf http://www.bad-doberan.de/uploads/media/Hausnummernsatzung.pdf http://www.grimmen.de/cgi-bin/homepage/grimmen/Satzung_Straszen-Hausnummern http://www.saalfeld.de/files/1097774A150/Satzung+ueber+Strassennamen+und+Hausnummern.pdf thank you for these references. I have noticed that all of them reference the BauGB §126, which seems to confirm that this is the legal basis for the numbering. So we can conclude that some Länder / Gemeinden (federal states / municipalities) will assign numbers to empty plots only as an exception (public needs or on request of the proprietor if he can prove a special requirement) and will assign numbers to every independently used building, while others (like the aforementioned Berlin) put the focus on the plot. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
2015-02-25 15:57 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: thank you for these references. I have noticed that all of them reference the BauGB §126, which seems to confirm that this is the legal basis for the numbering Are you kidding me? :-) 1. Neither http://www.rosenheim.de/uploads/media/631f.pdf nor http://www.bad-doberan.de/uploads/media/Hausnummernsatzung.pdf reference to BBauG. And there a lot of more. 2. Referencing to BBauG is meaningless, because every local law (Satzung) needs a landesrechtliche legislative http://www.dict.cc/englisch-deutsch/legislative.html basis. 2. Your thesis has been, that you not yet found any text that doesn't state that the plot is the main unit for numbering reason. That hav been the only reason for this list. 3. I have linked to an official http://www.dict.cc/englisch-deutsch/official.html headnote http://www.dict.cc/englisch-deutsch/headnotes.html (Leitsatz) which says the obviousness http://www.dict.cc/englisch-deutsch/obviousness.html The right to grant of house numbers based on ... [community law] We can conclude that (in Germany) it depends only on local law. We can conclude that there is no exception / general case plot/buildung We can conclude, that D.h., die Hausnummern beziehen sich in Deutschland grundsätzlich auf Grundstücke http://wiki.openstreetmap.org/wiki/DE:Karlsruhe_Schema#Rechtliche_Situation lacks any legal meaning. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 21.01.2015 08:28, Markus Lindholm wrote: Before we get carried away by a zillion relations I think we have to answer the questions as to what purpose do we want to explicitly associate an address with a POI or a building. Is it so that the data consumer can find her way to a POI? That's obviously superfluous as the POI already has a geographical location given. But not the address, according to your suggestion to keep addresses in separate nodes. Concerning buildings, an address node is imprecise. It may be on one side of the building, while you'd better come from the other side of the building. Search Nominatim for my postal address Davidgasse 76-80 and click the House in the search results. You couldn't achieve that with a single address node. In fact, the address node would be at the southern end of the building complex, while I live at the northern end, so you wouldn't find your way to my appartement. The only purpose I can think of is to facilitate for the data consumer to send a physical letter to the POI and that is a bit of a fringe use case. With buildings is even murkier as to what the purpose would be. Is there any country where the address would be part of the ID for the building in the cadastre? Seems unlikely as a building can have many addresses. I think that we don't need to care about the cadastre. It's something independent from OSM. I think we should generally not ponder about application purposes too much. The purpose of tagging is to represent data in a clean and unambigous way. Leave it over to applications to do something with it or not. If someone wants to make a carnival report on whether buildings with even or odd housenumbers are larger, why not? So I'm not advocating that a zillion relation be created, just that if you REALLY need an EXPLICIT association between an address and a POI/building then you should use a relation. And that addresses would be stored in the database in a coherent manner. That mixes the needs of mappers and data consumers. As a mapper, I don't need such an association at all. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
Hi Friedrich. I can't say for whole World, as for Russia we have plots of lands having addresses without buildings. They are not always dedicated to be build up with something. There is three ways, (maybe more, but i don't know for sure): 1. Large landuses as landuse=industrial may have their own address, like. Springfield, Green Road, 123. and every building inside this territory have their own address like: Springfield, Green Road, 123, building 2. (Keep in mind that we traditionally have different addresses parts order). 2,3. Rather small land lots with demolished or not yet constructed buildings. We can say that they are dedicated to be built up with something in future, but they may appears empty for ages. It's rather common situation for rural areas, when owner have purchased land lot, but haven't built capital house yet. But these lots should have addresses for mail correspondence and fees. Wed, 21 Jan 2015 21:02:14 -0600 от John F. Eldredge j...@jfeldredge.com: On 01/19/2015 03:39 AM, Friedrich Volkmann wrote: On 18.01.2015 22:23, Markus Lindholm wrote: I think that comes down to how addresses are viewed, either as a proper feature in their one right or as an attribute to some other feature. Yes, that's the crux. I think addresses are proper features, so a distinct address should be found only once in the database. And I see it the other way. Addresses are just attributes. It may pendend on the country, I don't know. In Austria and most certainly in entire central Europe, an address is always bound to a building, apartment or strictly delimited plot of land. An address cannot exist on its own. Every address includes a housenumber, indicating that there's a house. There are no addresses in the midst of a lake or somewhere in the cliffs. If you have a strictly delimited plot of land, with no house currently built upon it, but which is intended for later construction, does it have a house number? Or is the address only assigned once a building is built? -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that. Dr. Martin Luther King, Jr. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 22.01.2015 04:02, John F. Eldredge wrote: If you have a strictly delimited plot of land, with no house currently built upon it, but which is intended for later construction, does it have a house number? Or is the address only assigned once a building is built? When it is already intended for later construction, it usually already has an address (including house number or conscription number) assigned. But again, I can only speak of Austria. So we have three levels of estimated vs. fully surveyed address mapping: 1) address nodes: we know that the address is valid somewhere around that point 2) address as building attribute: we know at least one building where the the address is valid 3) address as plot attribute: we know the entire area where the address is valid Of course, the building may occupy the whole plot, especially in cities. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
Am 22.01.2015 um 04:02 schrieb John F. Eldredge: If you have a strictly delimited plot of land, with no house currently built upon it, but which is intended for later construction, does it have a house number? Or is the address only assigned once a building is built? In Germany the address always belongs to the plot and not to the building and they are assigned in advance. cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 19.01.2015 12:37, Markus Lindholm wrote: Treating addresses as attributes might be fast and convenient but that kind of scheme becomes incoherent as there is no one-to-one relationship between addresses and other features. E.g. - There are MULTIPLE POIs that all relate to ONE address - There are MULTIPLE addresses that all relate to ONE building So you would end up with a database where the address information is stored all over the place and no coherent way to process it. Better to have bare address nodes and when necessary use a relation to create an association between the address and other features. We already have zillions of POIs (e.g. shop nodes) with address attributes. If you wanted to keep address information separate, you would need to add just as many address nodes and relations. You would even need to separate all addresses from buildings. So your vision is not only incompatible with the addrN scheme, it is incompatible with how addresses are used in OSM altogether. You apparently wish to implement a relational database concept for address information, but this is just impossible because OSM is not a relational database. All data in OSM directly or indirectly contains geographical information. When you use a relation to connect a shop node (which has geographical coordinates) to an address node (which as geographical coordinates), you have two conflicting sets of geographical coordinates. So if you are looking for normalisation, you need to get rid of the address nodes altogether and set the adress tags on the relation directly. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 19.01.2015 12:47, Andrew Shadura wrote: It doesn't actually matter if you agree or not, because it doesn't change the fact that buildings in CZ and SK don't have multiple addresses. I cannot judge this. If this is a fact, addr2 is not needed or even plain wrong for conscription numbers in CZ and SK. The addrN scheme just offers a syntax for alternate addresses. Use it where applicable, and don't use it where it is not applicable. The conscription number example in my version of the proposal is from Austria, where it is applicable. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 19 January 2015 at 11:08, Friedrich Volkmann b...@volki.at wrote: That's wrong, as I've already explained in another message. When you write a letter to an address in Austria using a conscription number, you MUST omit the street name. Otherwise the letter will be returned as undeliverable. Similarly, the official address at a given time either contains a street+housenumber or a conscription number, not both. In villages where street+housenumber combinations are introduced, the conscription numbers become officially invalid. The reason why we want to keep them in OSM is that conscription numbers often remain in use for a long time, and the conscription number plates often stay in place (see photos in the proposals). Both statements are actually untrue. -- Cheers, Andrew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
Andrew, anyway they are mapped in osm as addresses (ok special kind of addresses), and used in the way addresses usually used. Addresses are still distinct as they was There is only one building for Praha, 606 and only one building for Praha, Staroměstské náměstí, 11 Same story for Tallin: There is only one Tallinn, Pikk, 9 and only one Tallinn, Lai, 8 But they both shares one building. And if I understand my Estonian colleagues, both of them are official, at least both of them could be found in official GIS maaamet. And I could add more countries and schemes and examples. Addresses are distinct, POIs are distinct, buildings are distinct, but their conjunctions are not. Maybe we just use term distinct for different things? There are many ways to have distinct addresses, and distinct objects with one or more addresses and If a developer have designed database with assumption that there could be only one address, and in real world he have found an object with two addresses, he have made a wrong assumption, not the reality is wrong. Mon, 19 Jan 2015 09:57:04 +0100 от Andrew Shadura and...@shadura.me: On 19 January 2015 at 05:54, Dmitry Kiselev dkise...@osm.me wrote: So we have 2 millions things in OSM going against OSM modeling tradition: http://taginfo.openstreetmap.org/keys/addr%3Aconscriptionnumber It's same story, two addresses for one object. First: hn-street-city Second: hn-city Scheme is different, but principle is the same, two addresses for one object via tags. Dmitry, this isn't true. Conscription number/street number is just a special sort of an address, it's not like two totally separate addresses. Yes, you can use a part of it to address a building (conscription number + optional street + optional locality name + city), but anyway the official address is still just one. -- Cheers, Andrew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 19.01.2015 10:41, Andrew Shadura wrote: On 19 January 2015 at 11:08, Friedrich Volkmann b...@volki.at wrote: That's wrong, as I've already explained in another message. When you write a letter to an address in Austria using a conscription number, you MUST omit the street name. Otherwise the letter will be returned as undeliverable. Similarly, the official address at a given time either contains a street+housenumber or a conscription number, not both. In villages where street+housenumber combinations are introduced, the conscription numbers become officially invalid. The reason why we want to keep them in OSM is that conscription numbers often remain in use for a long time, and the conscription number plates often stay in place (see photos in the proposals). Both statements are actually untrue. I have been living in this country for all my life, and I worked at a post office for some months. So you can safely believe my statements. But all you mind to say it that it's all untrue. Well, maybe you also say that the heliocentric system is untrue, and that Man was created 4000 BC. I hope you are fine in your universe. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
In my country, both numbers are used concurrently and together with street name Such thing, that you use conscription numbers and street numbers all together in a same time doesn't make conscription numbers not an address You've said: Praha, 606 might be not unique inside whole Praha without neighborhood name. Ok, in such case Praha, Central district, 606 should be unique, am I right? If conscription numbers, in your country are not valid without quarter or district or block (I don't know how you name such subdivisions within cites) it should be tagged. And in such case, it's two addresses (ok they are binded together, it's not a problem), isn't it? Mon, 19 Jan 2015 11:10:11 +0100 от Andrew Shadura and...@shadura.me: On 19 January 2015 at 11:33, Friedrich Volkmann b...@volki.at wrote: I have been living in this country for all my life, and I worked at a post office for some months. So you can safely believe my statements. But all you mind to say it that it's all untrue. Well, maybe you also say that the heliocentric system is untrue, and that Man was created 4000 BC. I hope you are fine in your universe. If your country has effectively abolished conscription numbers, this is one thing. Another this is how they work in countries where they're used all the time. In my country, both numbers are used concurrently and together with street name, and this country together with a neighbouring country are the largest users of this addressing system to date. -- Cheers, Andrew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On Mon, Jan 19, 2015 at 10:56:01AM +0300, Dmitry Kiselev wrote: addr:city=ukrainian city name addr:street=ukrainian street name addr:housenumber=123 Is enough, all kind of translations might be taken from matched street/city as good as any kind of old_names or alt_names Good point. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
No, it's not two addresses, it's just a single one. It's just a particular feature of it that you can omit a part of it (either of the building numbers or sometimes the street name if you have the conscription number). I've got your point, but I cant agree with you that it's not a multiple addresses tagging scheme. Also I can't agree that there is no problems with points. And I can't agree that addrN breaks some of the OSM principles. Mon, 19 Jan 2015 12:14:09 +0100 от Andrew Shadura and...@shadura.me: On 19 January 2015 at 12:08, Dmitry Kiselev dkise...@osm.me wrote: In my country, both numbers are used concurrently and together with street name Such thing, that you use conscription numbers and street numbers all together in a same time doesn't make conscription numbers not an address I didn't say it's not an address at all, but it's not a separate address. It's just a part of a regular address. You've said: Praha, 606 might be not unique inside whole Praha without neighborhood name. Ok, in such case Praha, Central district, 606 should be unique, am I right? If conscription numbers, in your country are not valid without quarter or district or block (I don't know how you name such subdivisions within cites) it should be tagged. Addr:street + addr:conscriptionnumber + addr:streetnumber (if exists) is enough on a building to be correctly addressed in most of the cases except where a building administratively belongs to a different district in which it is located geographically, or if it's a village with no street numbers (those a special cases we're not talking about at the moment). And in such case, it's two addresses (ok they are binded together, it's not a problem), isn't it? No, it's not two addresses, it's just a single one. It's just a particular feature of it that you can omit a part of it (either of the building numbers or sometimes the street name if you have the conscription number). -- Cheers, Andrew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 19 January 2015 at 11:33, Friedrich Volkmann b...@volki.at wrote: I have been living in this country for all my life, and I worked at a post office for some months. So you can safely believe my statements. But all you mind to say it that it's all untrue. Well, maybe you also say that the heliocentric system is untrue, and that Man was created 4000 BC. I hope you are fine in your universe. If your country has effectively abolished conscription numbers, this is one thing. Another this is how they work in countries where they're used all the time. In my country, both numbers are used concurrently and together with street name, and this country together with a neighbouring country are the largest users of this addressing system to date. -- Cheers, Andrew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
If you mean osm relation between POI and every address node, such schema will not ever be widely in use. As for relational databases, yep one more SQL relation is an option. And for noSQL data storages there are hundred ways to store such relationships. Mon, 19 Jan 2015 12:37:32 +0100 от Markus Lindholm markus.lindh...@gmail.com: On 19 January 2015 at 10:39, Friedrich Volkmann b...@volki.at wrote: On 18.01.2015 22:23, Markus Lindholm wrote: I think addresses are proper features, so a distinct address should be found only once in the database. And I see it the other way. Addresses are just attributes. It may pendend on the country, I don't know. Treating addresses as attributes might be fast and convenient but that kind of scheme becomes incoherent as there is no one-to-one relationship between addresses and other features. E.g. - There are MULTIPLE POIs that all relate to ONE address - There are MULTIPLE addresses that all relate to ONE building So you would end up with a database where the address information is stored all over the place and no coherent way to process it. Better to have bare address nodes and when necessary use a relation to create an association between the address and other features. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 19.01.2015 09:57, Andrew Shadura wrote: Dmitry, this isn't true. Conscription number/street number is just a special sort of an address, it's not like two totally separate addresses. Yes, you can use a part of it to address a building (conscription number + optional street + optional locality name + city), but anyway the official address is still just one. That's wrong, as I've already explained in another message. When you write a letter to an address in Austria using a conscription number, you MUST omit the street name. Otherwise the letter will be returned as undeliverable. Similarly, the official address at a given time either contains a street+housenumber or a conscription number, not both. In villages where street+housenumber combinations are introduced, the conscription numbers become officially invalid. The reason why we want to keep them in OSM is that conscription numbers often remain in use for a long time, and the conscription number plates often stay in place (see photos in the proposals). One other important aspect is that although addr:conscriptionnumber is in use in some regions, it is not documented on http://wiki.openstreetmap.org/wiki/Key:addr. That's why all conscription numbers in Austria are mapped as addr:housenumber. We cannot use that key for the street-housenumber and the conscriptionnumber at the same time, so we need addr2 to map both. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 19.01.2015 11:10, Andrew Shadura wrote: If your country has effectively abolished conscription numbers, this is one thing. Another this is how they work in countries where they're used all the time. In my country, both numbers are used concurrently and together with street name, and this country together with a neighbouring country are the largest users of this addressing system to date. My country has not abolished conscription numbers. Originally all communes used conscription numbers. All cities abolished them long ago, but some rural communes still use them, or are in transition. Remember that conscription numbers where introduced in the 18th century when Bohemia, Moravia and Slovakia were all part of Austria, so it's actually the same system, or at least it was originally. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 18.01.2015 22:23, Markus Lindholm wrote: I think that comes down to how addresses are viewed, either as a proper feature in their one right or as an attribute to some other feature. Yes, that's the crux. I think addresses are proper features, so a distinct address should be found only once in the database. And I see it the other way. Addresses are just attributes. It may pendend on the country, I don't know. In Austria and most certainly in entire central Europe, an address is always bound to a building, apartment or strictly delimited plot of land. An address cannot exist on its own. Every address includes a housenumber, indicating that there's a house. There are no addresses in the midst of a lake or somewhere in the cliffs. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
No, it's not two addresses, it's just a single one. It's just a particular feature of it that you can omit a part of it (either of the building numbers or sometimes the street name if you have the conscription number). I've got your point, but I cant agree with you that it's not a multiple addresses tagging scheme. It doesn't actually matter if you agree or not, because it doesn't change the fact that buildings in CZ and SK don't have multiple addresses. -- Cheers, Andrew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
So we have 2 millions things in OSM going against OSM modeling tradition: http://taginfo.openstreetmap.org/keys/addr%3Aconscriptionnumber It's same story, two addresses for one object. First: hn-street-city Second: hn-city Scheme is different, but principle is the same, two addresses for one object via tags. Sun, 18 Jan 2015 21:52:20 +0100 от Markus Lindholm markus.lindh...@gmail.com: On 17 January 2015 at 22:16, Friedrich Volkmann b...@volki.at wrote: With the addrN schema, we need one object (a node tagged shop=* and addrN:*=*) for a shop. With the provides_feature relation we need one node for the shop, one node for each address, and one relation. And if there are two shops that both have the same address? Then your scheme breaks down as you would end up with a database with two distinct nodes but same address. Clearly a bad thing and against the principle of 'One feature - one element' http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element The provides_feature relation may be fine for entrances and parking places, but using it for addresses adds too much unnecessary complexity to the database. I am not sure if the address role is bad, but we shouldn't use it in cases where we can do without that relation. If there is a need to explicitly associate one or more addresses with a building I don't see any other coherent way. Shoehorning multiple address into single object just goes against how things are modelled in OSM /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On Sat, Jan 17, 2015 at 11:11:23PM +0100, Friedrich Volkmann wrote: On 16.01.2015 05:48, Ineiev wrote: On Thu, Jan 15, 2015 at 12:53:13PM +0100, Martin Koppenhoefer wrote: you could use polygons (e.g. 2 distinct multipolygons, one for each address), and add a note to inform your fellow mapping colleagues that the overlap is intended (note is not needed but nice). I think this solution has an essential advantage: distinct multipoligons with single addr:housenumbers can go do distinct associatedStreet relations. you can't do it with addrN:; and the mapper may want to use associatedStreet e.g. because it provides a way to specify parallel addresses in different languages (I believe, this feature is used in countries like Ukraine). If we need language versions for the street name, we'll probably need them for city names (Kiyev/Kiyiv) etc. too. So you'll not only need an associatedStreet relation, but also an associatedCity relation. TTBOMK the city/country part of the address comes from the city multipoligon, and it does have an established way to specify localized versions. You can (mis-)use the addrN schema for that purpose: addr:city=ukrainian city name addr:street=ukrainian street name addr:housenumber=123 addr:2:city=russian city name addr:2:street=russian street name addr:2:housenumber=123 Indeed, it would be a misuse. the user of data should be able to identify the language. The number of tags multiplies with the number of street/housenumber combinations, but that may still be simpler than congruent housenumber polygons all of which are member of several associatedSomething relations. I think that the best solution may be: addr:city=ukrainian city name addr:city:ru=russian city name addr:street=ukrainian street name addr:street:ru=russian street name addr:housenumber=123 Agreed; but those would be a bunch of new tags, while associatedStreet is already documented in wiki and hopefully supported by software. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
Markus, there is no problems with distinct addresses at all if you treat them as first class citizen in your database. Table address id, scheme, hn, street, quarter, neighbourhood, city, e.t.c Table POI id, name, brand, operator, something, else Table POI_Addr POI (POI.id), addr (address.id) So you'll get distinct addresses and distinct POI with multiple addresses. Of course keeping two addresses (or three or more, look at the Vilnus) is more difficult than one address. But cause of this difficulties isn't an OSM tagging schema cause of this difficulties is multiple addressing itself. Me and Friedrich do not propose to trow away addr points or conscription numbers. There is a demand for addressing schema based on tags, and such schemes pop up every year. So I want, when somebody will find that he need to map 2 or more addresses and points (or anything else based on fake geometry) doesn't fit him, I want him to use addr2 and not addr:2 or addr_2 or street2+housenumber2. And if we don't have description for multiple addresses mapping via tags, it will be created and used without proposals and RFCs. Sun, 18 Jan 2015 22:23:30 +0100 от Markus Lindholm markus.lindh...@gmail.com: On 18 January 2015 at 22:11, Dan S danstowell+...@gmail.com wrote: 2015-01-18 20:52 GMT+00:00 Markus Lindholm markus.lindh...@gmail.com : On 17 January 2015 at 22:16, Friedrich Volkmann b...@volki.at wrote: With the addrN schema, we need one object (a node tagged shop=* and addrN:*=*) for a shop. With the provides_feature relation we need one node for the shop, one node for each address, and one relation. And if there are two shops that both have the same address? Then your scheme breaks down as you would end up with a database with two distinct nodes but same address. Clearly a bad thing and against the principle of 'One feature - one element' http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element This criticism is mistaken. (The wiki page even gives a counterexample of More than one of something on the same site which is rather similar to two shops with the same address.) We have lots of examples in OSM of two distinct objects with the same address - it's quite common in real life, and if it is a problem then it's nothing to do with addrN, it would be a problem with a large portion of our addr data! I think that comes down to how addresses are viewed, either as a proper feature in their one right or as an attribute to some other feature. I think addresses are proper features, so a distinct address should be found only once in the database. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
Am 17.01.2015 um 23:11 schrieb Friedrich Volkmann: On 16.01.2015 05:48, Ineiev wrote: On Thu, Jan 15, 2015 at 12:53:13PM +0100, Martin Koppenhoefer wrote: you could use polygons (e.g. 2 distinct multipolygons, one for each address), and add a note to inform your fellow mapping colleagues that the overlap is intended (note is not needed but nice). I think this solution has an essential advantage: distinct multipoligons with single addr:housenumbers can go do distinct associatedStreet relations. you can't do it with addrN:; and the mapper may want to use associatedStreet e.g. because it provides a way to specify parallel addresses in different languages (I believe, this feature is used in countries like Ukraine). If we need language versions for the street name, we'll probably need them for city names (Kiyev/Kiyiv) etc. too. So you'll not only need an associatedStreet relation, but also an associatedCity relation. You can (mis-)use the addrN schema for that purpose: addr:city=ukrainian city name addr:street=ukrainian street name addr:housenumber=123 addr:2:city=russian city name addr:2:street=russian street name addr:2:housenumber=123 The number of tags multiplies with the number of street/housenumber combinations, but that may still be simpler than congruent housenumber polygons all of which are member of several associatedSomething relations. I think that the best solution may be: addr:city=ukrainian city name addr:city:ru=russian city name addr:street=ukrainian street name addr:street:ru=russian street name addr:housenumber=123 +1 for language sufix. cu ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
Addresses are funny beasts. They may mean something different for the delivery guy, the mailman, the administration, the owner of the building, the cab driver who needs to let out a passenger. Maybe we should also indicate whether we mapped the ground parcel, the building, the doorbell, the mailbox, the service road/footway leading to the house... If you want to have both addresses and POIs only once, your only option is to use relations to tie them together unambiguously. In The Netherlands I found places where the address of the ground floor appartment differs from the appartment built on top of it. Do we have a good way to map those? The 'front' doors were in the back and one had to climb stairs to get to them. I don't really have an opinion. All I know is that in The Netherlands they now mapped multiple house numbers on dedicated nodes , which they placed withing the building contour in some diagonal fashion, and sometimes there are more than 10 for the same building. No idea if more than 100 also occurs. These are actual housenumbers not flat numbers. In Brussels we simply put 2 nodes inside the corner buildings. Buildings with 2 addresses are quite common there too. Both the addresses in Brussels and The Netherlands were imported from sources with a suitable license. Jo 2015-01-18 22:23 GMT+01:00 Markus Lindholm markus.lindh...@gmail.com: On 18 January 2015 at 22:11, Dan S danstowell+...@gmail.com wrote: 2015-01-18 20:52 GMT+00:00 Markus Lindholm markus.lindh...@gmail.com: On 17 January 2015 at 22:16, Friedrich Volkmann b...@volki.at wrote: With the addrN schema, we need one object (a node tagged shop=* and addrN:*=*) for a shop. With the provides_feature relation we need one node for the shop, one node for each address, and one relation. And if there are two shops that both have the same address? Then your scheme breaks down as you would end up with a database with two distinct nodes but same address. Clearly a bad thing and against the principle of 'One feature - one element' http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element This criticism is mistaken. (The wiki page even gives a counterexample of More than one of something on the same site which is rather similar to two shops with the same address.) We have lots of examples in OSM of two distinct objects with the same address - it's quite common in real life, and if it is a problem then it's nothing to do with addrN, it would be a problem with a large portion of our addr data! I think that comes down to how addresses are viewed, either as a proper feature in their one right or as an attribute to some other feature. I think addresses are proper features, so a distinct address should be found only once in the database. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 18 January 2015 at 22:11, Dan S danstowell+...@gmail.com wrote: 2015-01-18 20:52 GMT+00:00 Markus Lindholm markus.lindh...@gmail.com: On 17 January 2015 at 22:16, Friedrich Volkmann b...@volki.at wrote: With the addrN schema, we need one object (a node tagged shop=* and addrN:*=*) for a shop. With the provides_feature relation we need one node for the shop, one node for each address, and one relation. And if there are two shops that both have the same address? Then your scheme breaks down as you would end up with a database with two distinct nodes but same address. Clearly a bad thing and against the principle of 'One feature - one element' http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element This criticism is mistaken. (The wiki page even gives a counterexample of More than one of something on the same site which is rather similar to two shops with the same address.) We have lots of examples in OSM of two distinct objects with the same address - it's quite common in real life, and if it is a problem then it's nothing to do with addrN, it would be a problem with a large portion of our addr data! I think that comes down to how addresses are viewed, either as a proper feature in their one right or as an attribute to some other feature. I think addresses are proper features, so a distinct address should be found only once in the database. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 16.01.2015 11:40, Markus Lindholm wrote:
What we don't need is yet another special case mapping scheme like addrN
Have you had the time to look at the existing relation of
type=provides_feature
http://wiki.osm.org/wiki/Relations/Proposed/Provides_feature
and how you can use it to associate multiple addresses to a building.
Be aware that you are referring to another proposal that is not approved.
This bears the danger of circular disapprovals:
A is disapproved because B exists
B is disapproved because C exists
C is disapproved because A exists
That said, I'll give you my opinion on the provides_feature relation:
- It should include the {{Proposal_Page}} template and an RFC start date.
- It should include at least one example.
- The general concept seems reasonable.
- It's a relation. In most cases, it takes one relation per map feature.
That's too much.
- It relies on address nodes, which further increases the number of OSM objects.
We already have too many relations, and editing an area becomes harder and
harder. We always need to step through long lists of relations to make sure
we don't damage one. provides_features relations do not even have names, so
all we see in the relation list is a bunch of ids. Of course we can improve
editors to use different colors for different relation types. But wait - web
editors like Potlatch and ID don't display relations at all. Anybody using
these editors will damage the relations, or at least not create these
relations when needed.
With the addrN schema, we need one object (a node tagged shop=* and
addrN:*=*) for a shop.
With the provides_feature relation we need one node for the shop, one node
for each address, and one relation.
The mostly used argument against addrN is that it is not yet supported by
applications. The provides_feature relation is not yet supported either.
The provides_feature relation may be fine for entrances and parking places,
but using it for addresses adds too much unnecessary complexity to the
database. I am not sure if the address role is bad, but we shouldn't use
it in cases where we can do without that relation.
--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 16.01.2015 05:48, Ineiev wrote: On Thu, Jan 15, 2015 at 12:53:13PM +0100, Martin Koppenhoefer wrote: you could use polygons (e.g. 2 distinct multipolygons, one for each address), and add a note to inform your fellow mapping colleagues that the overlap is intended (note is not needed but nice). I think this solution has an essential advantage: distinct multipoligons with single addr:housenumbers can go do distinct associatedStreet relations. you can't do it with addrN:; and the mapper may want to use associatedStreet e.g. because it provides a way to specify parallel addresses in different languages (I believe, this feature is used in countries like Ukraine). If we need language versions for the street name, we'll probably need them for city names (Kiyev/Kiyiv) etc. too. So you'll not only need an associatedStreet relation, but also an associatedCity relation. You can (mis-)use the addrN schema for that purpose: addr:city=ukrainian city name addr:street=ukrainian street name addr:housenumber=123 addr:2:city=russian city name addr:2:street=russian street name addr:2:housenumber=123 The number of tags multiplies with the number of street/housenumber combinations, but that may still be simpler than congruent housenumber polygons all of which are member of several associatedSomething relations. I think that the best solution may be: addr:city=ukrainian city name addr:city:ru=russian city name addr:street=ukrainian street name addr:street:ru=russian street name addr:housenumber=123 -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 16.01.2015 17:04, Serge Wroclawski wrote: There is an addr:city=* key for the city, Is there a building in your dataset that lives in two cities? No. I used a bogus example just to demonstrate the syntax. And here's where we simply say: addr=val1;val2;val3 If you're in North America or a European country, it would be something like housnumber street name That's a similar approach as addr:full. So you use the mere addr=* key for half of the full address. I did not know, because it isn't documented on http://wiki.openstreetmap.org/wiki/Key:addr or http://wiki.openstreetmap.org/wiki/Addresses. Taginfo lists exactly 247 occurences of the addr=* key. The most common value is none. Let's say 123 Foo and 567 Bar addr:123 Foo;567 Bar Provided that you get along with just one addr=* key in place of the full addr:* schema, the semicolon notation seems reasonable. However, this is all hopothetical, as the addr=* key is not really in use and will certainly never become widely accepted. We can omit the city because the city is the same (if you have a real life counter example, please show me) and we can omit the postalcode for the same reason. So where do applications take the city and postcode from? Here you do not need to count semicolons, neither do applications. You can check address for address. Which solution do you like better? Maybe I'm mistaken, but it's my understanding that this solution is to address the exceptions in the data. I live in New York City, and we do have some buildings with multiple addresses, so this isn't a theoretical for me. We already dealth with this. There will be some exceptions, but not many. Even in a city like New York City, with over a million buildings (litterally), the number of multi-addressed buildings which we In most cases, going back to your first question, the solution was to use naked address nodes placed inside the building polygon. You asked how one would retrieve addresses from a data processing perspective. The answer is that in these cases, you *might* want to use some kind of building relation, and then you'd have the building as a relation and the nodes inside it, but what we did in NYC is to simply add naked address nodes inside the building polygon. That's a widespread habit in Europe too, but it's a defective concept, because 1) the scope of the addresses is not defined. Particularly, it is undefined whether both nodes apply to the whole building or each node applies to part of the building. 2) you cannot use address nodes to denote addresses of POIs which are nodes themselves. As an aside, it may be useful for someone to create some kind of an API or SDK on top of OSM to make it easy to retrieve these broad categories of data which may be represented in different ways. There are already databases with integrated all-purpose GIS functions, such as PostGIS. I agree that extensions for OSM specific data would also be useful. Many routines have been developed, few have been published. But everybody is free to do so. Anyway, a routine determining the scope of adresses will always fail for address nodes, because the scope is undefined by concept, see above. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 16 January 2015 at 01:04, Friedrich Volkmann b...@volki.at wrote: We can discuss its pros and cons, but I think the main message is that multiple addresses are mapped differently all over the world. Every country has its local OSM community which concoct their own tagging rules. The result is database full of tags that are understood by the local mappers, maybe by local applications too, but not by mappers or applications from other countries. We really need some unifying tagging scheme suitable for all kinds of addresses worldwide. What we don't need is yet another special case mapping scheme like addrN Have you had the time to look at the existing relation of type=provides_feature http://wiki.osm.org/wiki/Relations/Proposed/Provides_feature and how you can use it to associate multiple addresses to a building. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On Thu, Jan 15, 2015 at 8:29 PM, Friedrich Volkmann b...@volki.at wrote: In that scenario, I'd much prefer to see two nodes, each with their address, and each tagged as an entrance. What you prefer certainly depends on your needs. Adresses on entrances are fine for routing, maybe for visual representation too, but if you want to run a script generating a list of building sizes and addresses, you need addresses on buildings. I'll explain how we dealt with this issue in NYC later in the mail. What benefit does this proposal have over simply using a list separator? A list separator is fine as long as there is only one key. Unfortunately, there is no simple addr=* key. The addr key can be used on its own to denote a complete address, without using subkeys. The subkeys are preferable in most cases since they can be used to construct the keys themselves, but are not strictly necessary. There is an addr:city=* key for the city, Is there a building in your dataset that lives in two cities? an addr:postcode=* key for the postcode Postcode's an interesting one- but again, in actuality, do you have a building that has two postcodes? an addr:street=* key, and addr:housenumber=* key, and others. These are the two we care most about in this discussion. And here's where we simply say: addr=val1;val2;val3 If you're in North America or a European country, it would be something like housnumber street name Let's say 123 Foo and 567 Bar addr:123 Foo;567 Bar We can omit the city because the city is the same (if you have a real life counter example, please show me) and we can omit the postalcode for the same reason. Here you do not need to count semicolons, neither do applications. You can check address for address. Which solution do you like better? Maybe I'm mistaken, but it's my understanding that this solution is to address the exceptions in the data. I live in New York City, and we do have some buildings with multiple addresses, so this isn't a theoretical for me. We already dealth with this. There will be some exceptions, but not many. Even in a city like New York City, with over a million buildings (litterally), the number of multi-addressed buildings which we In most cases, going back to your first question, the solution was to use naked address nodes placed inside the building polygon. You asked how one would retrieve addresses from a data processing perspective. The answer is that in these cases, you *might* want to use some kind of building relation, and then you'd have the building as a relation and the nodes inside it, but what we did in NYC is to simply add naked address nodes inside the building polygon. This adds an extra step in data retrival, but it's not that bad. As an aside, it may be useful for someone to create some kind of an API or SDK on top of OSM to make it easy to retrieve these broad categories of data which may be represented in different ways. - Serge ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
I support using the addrN:* tagging proposed here in the specific situation where a single residence or business has multiple addresses. Note I am not referring to a building with multiple occupiers, but a single addressee with more than one address. In England I have never encountered this situation for residential addresses, but have done so very occasionally for shops and other businesses. Here is an example: http://www.openstreetmap.org/way/290380382 In cases like this there is probably only one 'official' address, but if the available sources are contradictory it is desirable to record both. This situation sometimes arises when a business decides their official address is confusing and they then invent another one which they think is clearer for people trying to find them. I think it's rarely a good idea to add the same feature twice, which is the obvious alternative for tagging this. I dislike the idea of using relations for multiple addresses because it's over-complicating things: a lot of mappers find relations confusing. I do not support using addrN:* tagging for the common case of multiple occupancy buildings. It simply does not work in a lot of cases, because different businesses in one building also require different names and other tags and I don't think we want to start using name:2=* office:2=*, and so on, to distinguish them. Cheers, Will On 15/01/2015 01:46, Friedrich Volkmann wrote: http://wiki.openstreetmap.org/wiki/Proposed_Features/addrN I once made a proposal for multiple addresses, which I think was fairly eleborate, but too complex. This is now a simplified version, and hopefully more acceptable. This tagging scheme is already in use (e.g. 7000 occurances of addr2:housenumber), but unfortunately limited to one country or so, due to a lack of international communication and documentation. I hope that this proposal will get it a wider audience, and that application support will subsequently improve. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
The idea, if I understand it, is to allow for some arbitrary number of values for an address. That's an important goal as we increase the number of addresses in OSM. I do have some questions/concerns about this specific proposal. As I examine it, it serves one very specific purpose, which is a building with two addresses. In my experience, this setup is often (not always) associated with a building with two entrances, each associated with an address. In that scenario, I'd much prefer to see two nodes, each with their address, and each tagged as an entrance. The other way I see these entrances used in real life is that one business or residence within a building uses one address, while another uses a different one. Here again, a POI would be more accurate and easier to parse. This leaves us with the scenario with a building which has both addresses associated with any entrance. So here we essentially a list of values. To that end, I don't see why we can't use the existing OSM list value separator, the semicolon, so the address is: addr=val1;val2;val3 This is advantageous to data users because without this, they would have to look for N arbitrary tags, as in addr, add2, add3, etc. What benefit does this proposal have over simply using a list separator? - Serge ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
Hello Friedrich, in Czech Republic they have a similar problem: They have so called conscription numbers, which are unique in the whole city and additionally the normal housenumbers. They use the key addr:streetnumber (675,742× used) for the number unique within the street, addr:conscriptionnumber (2,632,784× used) for the number unique within the city and addr:housenumber for both separated by a slash (tagging for the renderer?!). It's most likely not a solution to the problem you want to solve, where one house has two housenumbers unique within a street as far as I understand. But probably it's good to know about this similar problem. floscher Am 15.01.2015 um 02:46 schrieb Friedrich Volkmann: http://wiki.openstreetmap.org/wiki/Proposed_Features/addrN I once made a proposal for multiple addresses, which I think was fairly eleborate, but too complex. This is now a simplified version, and hopefully more acceptable. This tagging scheme is already in use (e.g. 7000 occurances of addr2:housenumber), but unfortunately limited to one country or so, due to a lack of international communication and documentation. I hope that this proposal will get it a wider audience, and that application support will subsequently improve. signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 15 January 2015 at 17:08, Florian Schäfer flor...@schaeferban.de wrote: Hello Friedrich, in Czech Republic they have a similar problem: They have so called conscription numbers, which are unique in the whole city and additionally the normal housenumbers. They use the key addr:streetnumber (675,742× used) for the number unique within the street, addr:conscriptionnumber (2,632,784× used) for the number unique within the city and addr:housenumber for both separated by a slash (tagging for the renderer?!). This isn't actually a problem in CZ and SK at all. Conscription number and street number are used by Nominatim, but they're intentionally not rendered. Housenumber tag is left to be used as human-readable house number (sometimes it's two numbers separated by a slash, sometimes it's only one which is more appropriate in the specific context). -- Cheers, Andrew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On Thu, Jan 15, 2015 at 4:10 AM, Dan S danstowell+...@gmail.com wrote: I was thinking about this solution too. The addrN scheme is really quite awkward so it'd be nice to recommend something like simply having two nodes/multipolygons with exactly the same overlapping geometry. However, this gets horrible too: if both of the addresses refer to a pub, should both objects be amenity=pub? (No!) Should they be grouped under a relation which holds amenity=pub other properties? Maybe, but that's getting just as awkward as addrN... It looks like there's a problem to be solved, and none of the solutions is pleasant. Hence I abstain ;) As far as I can understand, this issue only really becomes a problem with tagging an amenity, shop, office, etc. It made me wonder how the business advertises and get mail. I can't imagine businesses using two different addresses. Then again I've never lived anywhere with this problem. Has anyone asked the business owners which address they use? Rather than add to the tagging scheme, I think we should first try to understand it from the business viewpoint. If the business only uses one of the addresses, then the problem is solved with two nodes, ideally inside a building polygon. Clifford -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 15.01.2015 17:08, Florian Schäfer wrote: in Czech Republic they have a similar problem: They have so called conscription numbers, which are unique in the whole city and additionally the normal housenumbers. They use the key addr:streetnumber (675,742× used) for the number unique within the street, addr:conscriptionnumber (2,632,784× used) for the number unique within the city and addr:housenumber for both separated by a slash (tagging for the renderer?!). It's most likely not a solution to the problem you want to solve, where one house has two housenumbers unique within a street as far as I understand. But probably it's good to know about this similar problem. This exact approach is new to me. We can discuss its pros and cons, but I think the main message is that multiple addresses are mapped differently all over the world. Every country has its local OSM community which concoct their own tagging rules. The result is database full of tags that are understood by the local mappers, maybe by local applications too, but not by mappers or applications from other countries. We really need some unifying tagging scheme suitable for all kinds of addresses worldwide. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 15.01.2015 12:53, Martin Koppenhoefer wrote: you could use polygons (e.g. 2 distinct multipolygons, one for each address), and add a note to inform your fellow mapping colleagues that the overlap is intended (note is not needed but nice). That still separates the feature from its address, not in a topographical sense, but in the sense that tags for one feature are fragemented to multiple OSM objects. I wonder why multiple addresses are so loathed while multiple objects or even multiple relations for the same purpose are considered ok. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 15.01.2015 13:10, Dan S wrote: The addrN scheme is really quite awkward Can you explain why you find it awkward? It seems to me that the displeasure felt with the addrN scheme is caused by a phenomenon called transference. Multiple addresses in the real world are awkward, but they do exist and we cannot change that annoying fact. Therefore, the negative feeling transfers to the tagging scheme that represents the awkward reality. The awkward reality cannot be defeatet, but its representation can. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On Thu, Jan 15, 2015 at 4:04 PM, Friedrich Volkmann b...@volki.at wrote: This exact approach is new to me. We can discuss its pros and cons, but I think the main message is that multiple addresses are mapped differently all over the world. Every country has its local OSM community which concoct their own tagging rules. The result is database full of tags that are understood by the local mappers, maybe by local applications too, but not by mappers or applications from other countries. We really need some unifying tagging scheme suitable for all kinds of addresses worldwide. Address schemes that users can easily understand. If AddrN is approved, the address wiki page needs to be updated to clearly show the difference between multiple addresses in a building with multiple entrances and a building with multiple addresses for the same entrance. (If I understand the proposal correctly.) Possibly add something like rarely used. -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On Thu, Jan 15, 2015 at 12:53:13PM +0100, Martin Koppenhoefer wrote: you could use polygons (e.g. 2 distinct multipolygons, one for each address), and add a note to inform your fellow mapping colleagues that the overlap is intended (note is not needed but nice). I think this solution has an essential advantage: distinct multipoligons with single addr:housenumbers can go do distinct associatedStreet relations. you can't do it with addrN:; and the mapper may want to use associatedStreet e.g. because it provides a way to specify parallel addresses in different languages (I believe, this feature is used in countries like Ukraine). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
I never heard of alt_addr:*. Where is it documented? I could not find any documentation either. I only found it on taginfo by analogy to alt_name. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 15 January 2015 at 03:02, johnw jo...@mac.com wrote: The proposal seems to be a good solution to this problem. This particular proposal seems to be a terrible solution to this problem. It requires changes to the software, and the tagging scheme is ugly as hell. At the same time, there's much simpler and better solution: placing address nodes inside the building polygon. This is already used, supported by any sort of software which can process regular OSM address tags, and it's not as ugly as addrN:. -- Cheers, Andrew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 15.01.15 12:23, Andrew Shadura wrote: This particular proposal seems to be a terrible solution to this problem. It requires changes to the software, and the tagging scheme is ugly as hell. At the same time, there's much simpler and better solution: placing address nodes inside the building polygon. This is already used, supported by any sort of software which can process regular OSM address tags, and it's not as ugly as addrN:. 100% agreed. /al ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
2015-01-15 12:23 GMT+01:00 Andrew Shadura and...@shadura.me: On 15 January 2015 at 03:02, johnw jo...@mac.com wrote: The proposal seems to be a good solution to this problem. This particular proposal seems to be a terrible solution to this problem. It requires changes to the software, and the tagging scheme is ugly as hell. At the same time, there's much simpler and better solution: placing address nodes inside the building polygon. This is already used, supported by any sort of software which can process regular OSM address tags, and it's not as ugly as addrN:. With addrN:*=* it's clear that the same place has two addresses. If there are two nodes, it seems like there are two places (Two entrances, two apartments, two rooms), each with it's own address. AddrN* is clearly superior in this aspect. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 15.01.2015 08:41, Volker Schmidt wrote: What's the difference to alt_addr:xxx (http://taginfo.openstreetmap.org/search?q=alt_addr#keys), apart from the fact that addrN is used more frequently? I never heard of alt_addr:*. Where is it documented? It seems that alt_addr:* allows only one alternate address. addrN allows for more. You cannot use semicolon notation as in alt_name=*, because alt_name is one independent tag while alt_addr:* is a set of tags. Other point: I know that in the UK addresses may have two alternative forms: house name or number. This would also fall in this category and could be mentioned in the proposal page. This is already well known and documented on various wiki pages. I want to keep the proposal concise and focus on what's new. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
2015-01-15 12:43 GMT+01:00 Janko Mihelić jan...@gmail.com: With addrN:*=* it's clear that the same place has two addresses. If there are two nodes, it seems like there are two places (Two entrances, two apartments, two rooms), each with it's own address. AddrN* is clearly superior in this aspect. you could use polygons (e.g. 2 distinct multipolygons, one for each address), and add a note to inform your fellow mapping colleagues that the overlap is intended (note is not needed but nice). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
2015-01-15 11:53 GMT+00:00 Martin Koppenhoefer dieterdre...@gmail.com: 2015-01-15 12:43 GMT+01:00 Janko Mihelić jan...@gmail.com: With addrN:*=* it's clear that the same place has two addresses. If there are two nodes, it seems like there are two places (Two entrances, two apartments, two rooms), each with it's own address. AddrN* is clearly superior in this aspect. you could use polygons (e.g. 2 distinct multipolygons, one for each address), and add a note to inform your fellow mapping colleagues that the overlap is intended (note is not needed but nice). I was thinking about this solution too. The addrN scheme is really quite awkward so it'd be nice to recommend something like simply having two nodes/multipolygons with exactly the same overlapping geometry. However, this gets horrible too: if both of the addresses refer to a pub, should both objects be amenity=pub? (No!) Should they be grouped under a relation which holds amenity=pub other properties? Maybe, but that's getting just as awkward as addrN... It looks like there's a problem to be solved, and none of the solutions is pleasant. Hence I abstain ;) Best Dan ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 15 January 2015 at 12:43, Janko Mihelić jan...@gmail.com wrote: 2015-01-15 12:23 GMT+01:00 Andrew Shadura and...@shadura.me: On 15 January 2015 at 03:02, johnw jo...@mac.com wrote: The proposal seems to be a good solution to this problem. This particular proposal seems to be a terrible solution to this problem. It requires changes to the software, and the tagging scheme is ugly as hell. At the same time, there's much simpler and better solution: placing address nodes inside the building polygon. This is already used, supported by any sort of software which can process regular OSM address tags, and it's not as ugly as addrN:. With addrN:*=* it's clear that the same place has two addresses. If there are two nodes, it seems like there are two places (Two entrances, two apartments, two rooms), each with it's own address. AddrN* is clearly superior in this aspect. For an absolute majority of cases it should be enough with address nodes that resides inside a building polygon. If their really is a need to explicitly associate multiple addresses to a single building then use the provides_feature relation. http://wiki.osm.org/wiki/Relations/Proposed/Provides_feature /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 15.01.2015 17:29, Serge Wroclawski wrote: As I examine it, it serves one very specific purpose, which is a building with two addresses. It can also be applied to other areas (e.g. parcels) or nodes (e.g. shop nodes). Of course, the common crux is the existence of two or more equivalent addresses. In my experience, this setup is often (not always) associated with a building with two entrances, each associated with an address. In that scenario, I'd much prefer to see two nodes, each with their address, and each tagged as an entrance. What you prefer certainly depends on your needs. Adresses on entrances are fine for routing, maybe for visual representation too, but if you want to run a script generating a list of building sizes and addresses, you need addresses on buildings. The other way I see these entrances used in real life is that one business or residence within a building uses one address, while another uses a different one. Here again, a POI would be more accurate and easier to parse. Yes. This leaves us with the scenario with a building which has both addresses associated with any entrance. Yes, that case is the main reason for the proposal. So here we essentially a list of values. To that end, I don't see why we can't use the existing OSM list value separator, the semicolon, so the address is: addr=val1;val2;val3 This is advantageous to data users because without this, they would have to look for N arbitrary tags, as in addr, add2, add3, etc. What benefit does this proposal have over simply using a list separator? A list separator is fine as long as there is only one key. Unfortunately, there is no simple addr=* key. There is an addr:city=* key for the city, an addr:postcode=* key for the postcode, an addr:street=* key, and addr:housenumber=* key, and others. One complete address is therefore represented by a whole set of keys. So if you use list separators, you have: addr:city=val1;val2;val3 addr:postcode=val4;val5;val6 addr:street=val7;val8;val9 addr:housenumber=val10;val11;val12 This is possible, but error-prone, particularly with longer address parts: addr:city=New York; Llanfairpwllgwyngyllgogerychwyrndrobwantysiliogogogoch; Ho Chi Minh City addr:postcode=14324;45345,343;5645 addr:street=Red Street; Rue Morgue; Blue Street: Green Street addr:housenumber=1;4;3;2;4 How long do you take to spot the errors? How will applications handle that data? And if one of the addresses really lacks one of the address parts (e.g. no street in case of a conscription number), you end up with an empty list element, e.g.: leading separator: addr:street=;Rue Morgue; Blue Street; Green Street or two consecutive separators: addr:street=Red Street; ; Blue Street; Green Street or a trailing separator: addr:street=Red Street; Rue Morgue; Blue Street; Green Street; With the addrN scheme, these addresses would be represented like this: addr:city=New York addr:postcode=14324 addr:street=Red Street addr:housenumber=1 addr2:city=Llanfairpwllgwyngyllgogerychwyrndrobwantysiliogogogoch addr2:postcode=45345 addr2:street=Rue Morgue addr2:housenumber=4 addr3:city=... ... Here you do not need to count semicolons, neither do applications. You can check address for address. Which solution do you like better? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On Jan 15, 2015, at 8:43 PM, Janko Mihelić jan...@gmail.com wrote: 2015-01-15 12:23 GMT+01:00 Andrew Shadura and...@shadura.me mailto:and...@shadura.me: On 15 January 2015 at 03:02, johnw jo...@mac.com mailto:jo...@mac.com wrote: The proposal seems to be a good solution to this problem. This particular proposal seems to be a terrible solution to this problem. It requires changes to the software, and the tagging scheme is ugly as hell. At the same time, there's much simpler and better solution: placing address nodes inside the building polygon. This is already used, supported by any sort of software which can process regular OSM address tags, and it's not as ugly as addrN:. With addrN:*=* it's clear that the same place has two addresses. If there are two nodes, it seems like there are two places (Two entrances, two apartments, two rooms), each with it's own address. AddrN* is clearly superior in this aspect. +1 Why have two pins for the same (exact) place. If this was the case that a building had multiple addresses because it had multiple named locations or multiple names entrances or whatnot, such as two offices or two gates, then yea, two pins would be appropriate. But that doesn’t seem to be the case. This seems to be a a single building that itself has two contrasting addresses. why tag the same thing twice? that seems counter-intuitive. We already have like what, how many different name fields and alt names and official names and everything - but addr2 requires a split - though it’s the same address for the same place in the same location? Especially if this tag is already in use in regions where this unique thing occurs - lets document it so it doesn’t get out of hand or get fragged so support for it becomes truly PITA. Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - addrN:*
http://wiki.openstreetmap.org/wiki/Proposed_Features/addrN I once made a proposal for multiple addresses, which I think was fairly eleborate, but too complex. This is now a simplified version, and hopefully more acceptable. This tagging scheme is already in use (e.g. 7000 occurances of addr2:housenumber), but unfortunately limited to one country or so, due to a lack of international communication and documentation. I hope that this proposal will get it a wider audience, and that application support will subsequently improve. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
That’s really interesting. I had no idea there were locations with more than 1 commonly used address. The proposal seems to be a good solution to this problem. Javbw On Jan 15, 2015, at 10:46 AM, Friedrich Volkmann b...@volki.at wrote: http://wiki.openstreetmap.org/wiki/Proposed_Features/addrN I once made a proposal for multiple addresses, which I think was fairly eleborate, but too complex. This is now a simplified version, and hopefully more acceptable. This tagging scheme is already in use (e.g. 7000 occurances of addr2:housenumber), but unfortunately limited to one country or so, due to a lack of international communication and documentation. I hope that this proposal will get it a wider audience, and that application support will subsequently improve. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
What's the difference to alt_addr:xxx ( http://taginfo.openstreetmap.org/search?q=alt_addr#keys), apart from the fact that addrN is used more frequently? Other point: I know that in the UK addresses may have two alternative forms: house name or number. This would also fall in this category and could be mentioned in the proposal page. On 15 January 2015 at 02:46, Friedrich Volkmann b...@volki.at wrote: http://wiki.openstreetmap.org/wiki/Proposed_Features/addrN I once made a proposal for multiple addresses, which I think was fairly eleborate, but too complex. This is now a simplified version, and hopefully more acceptable. This tagging scheme is already in use (e.g. 7000 occurances of addr2:housenumber), but unfortunately limited to one country or so, due to a lack of international communication and documentation. I hope that this proposal will get it a wider audience, and that application support will subsequently improve. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
