Openstreetmap-carto: conscription numbers

[fkv1]

addr:conscriptionnumber is currently never rendered. It would be nice if it could be rendered whenever addr:housenumber would be rendered but is not present. I mean like NVL(addr:housenumber, addr:conscriptionnumber) in SQL.

[matkoniecz]

It would be useful to explain at http://wiki.openstreetmap.org/wiki/Key:addr:conscriptionnumber why it may be used instead of addr:housenumber, as it is not obvious why standard tags are not used.

Also, in 99,53% cases according to http://taginfo.openstreetmap.org/keys/addr%3Aconscriptionnumber#combinations addr:housenumber is anyway present - is it possible that it is only addr:conscriptionnumber may be tagged?

[dieterdreist]

sent from a phone

Am 04.01.2016 um 08:11 schrieb Mateusz Konieczny [email protected]:

It would be useful to explain at http://wiki.openstreetmap.org/wiki/Key:addr:conscriptionnumber why it is used instead of addr:housenumber, as it is not obvious why standard tags are not used

addr:conscriptionnumber IS the standard tag for conscription numbers

[matkoniecz]

The problem is that from reading http://wiki.openstreetmap.org/wiki/Key:addr:conscriptionnumber it is not clear what is conscription number and how it is related to house number.

Contains house numbers originally known as "Konskriptionsnummer"

seems to imply that addr:conscriptionnumber should be always accompanied by exactly the same addr:housenumber. But "It would be nice if it could be rendered whenever addr:housenumber would be rendered but is not present." request makes clear that I missing something.

[Klaus-Tockloth]

Conscription numbers are, in opposite to house numbers, not intended for orientation.

[fkv1]

Conscription numbers were introduced in the 18th century in the Austro-Hungarian Empire. Houses got numbers that were unique within the respective settlement. Those numbers were used for the cadastre and for taxation, but not for deliveries. Distribution of conscription numbers was virtually random. There could be house number 9876 beside house number 1. When it turned out that orientation numbers (house numbers unique within the street) are more practicable, conscription numbers in big towns were soon replaced by orientation numbers, at least in Austria. But conscription numbers are still in use in many small and/or dispersed settlements, and apparently in bigger settlements too when we look at CZ/SK. That may explain why CZ/SK mappers invented the addr:conscriptionnumber key. As far as I can see, they merge conscription number and orientation number together into addr:housenumber, using a slash as delimiter. This seems like a bad hack to get them both rendered. We cannot do that in AT, because the slash is commonly used as the delimiter between housenumber / staircase number / level number / door number, when they are combined for printing. Instead, we have commonly been using another hack: We used addr:housenumber for either the orientation or the conscription number, and threw away the other one. The addr:conscriptionnumber tag was rarely ever used in AT or anywhere else outside CZ/SK, because we did not know about that tag, and also because it has not been supported by applications, particularly Carto and Nominatim. So that are the reasons why >99% of the addr:conscriptionnumber tags are within CZ/SK, and accompanied by addr:housenumber tags.

[d1g]

why it may be used instead of addr:housenumber, as it is not obvious why standard tags are not used.

Conscription numbers shouldn't be tagged in addr:housenumber. addr:conscriptionnumber is more about ref=* tag than regular addr:housenumber.

Main style may treat addr:conscriptionnumber as alias to addr:housenumber.
Nominatim may treat addr:conscriptionnumber as alias to addr:housenumber.

addr:conscriptionnumber tags are within CZ/SK, and accompanied by addr:housenumber tags.

Second tag addr:housenumber should be removed after software is fixed.

addr:conscriptionnumber were supported for years: https://github.com/kiselev-dv/gazetteer/search?utf8=%E2%9C%93&q=conscriptionnumber&type=Code
https://github.com/search?q=conscriptionnumber&type=Code&utf8=%E2%9C%93

[d1g]

@fkv1, I encourage to remove addr:housenumber ASAP from conscription numbers (but keep them in addr:conscriptionnumber)

There could be house number 9876 beside house number 1.

Is opposite to what most addr:housenumber (mostly European street numbers) consumers would like to see:

• (roughly) linear numbering (house 300 in practice means "other side of the city" and NOT building close to 1)
• odd/even sides of the street

... better explanation in my blog http://www.openstreetmap.org/user/d1g/diary/38041

[matkoniecz]

Second tag addr:housenumber should be removed after software is fixed.

Either this tagging is wrong and should be fixed now ( http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer ) or it is OK and there is need for fixing it.

[matthijsmelissen]

Even if we would take conscription numbers into account, there will be many other data consumers who don't (and are not likely to adapt the code for such a regional specific feature). Therefore, I think the solution with addr:housenumber containing both conscription and sequential numbers, is the best. This is already the case at least in the Czech Republic. As addr:housenumber already contains the conscription number, I don't think it makes sense for us to render conscription numbers.

[aceman444]

The tagging in housenumber is not as wrong as it seems. Many businesses that have a common address (streetnumber) with other ones also use the building (conscription) number as part of their official address. Also some state registers officially use both concriptionnumber/streetnumber (with the slash!) as part of a citizen's address. So putting this string into housenumber and rendering it (with) the slash is mostly correct and almost everybody in CZ/SK understands what it means and can use the number (and split as necessary). You can check even Google maps displays the addresses in this format.

[fkv1]

It may be understood in CZ/SK, but it is not understood in AT or anywhere else in the world. As math1985's suggested solution obviously does not work outside CZ/SK, he should not have closed the issue.

[d1g]

Even if we would take conscription numbers into account, there will be many other data consumers who don't (and are not likely to adapt the code for such a regional specific feature).

@math1985 this repository is about carto style/it's pipelines, not about other software.

We shouldn't retag objects only based what our/their software supports. Retagging should occur only according tagging proposals/use cases/definitions/wiki. If there some software that doesn't support tag X, we shouldn't care at all http://wiki.openstreetmap.org/wiki/Any_tags_you_like.

Use case with conscription numbers:
they are not meant for orientation
https://github.com/gravitystorm/openstreetmap-carto/issues/2016#issuecomment-168641485
they are not meant to be used globally or not understood by non-locals in practice
https://github.com/gravitystorm/openstreetmap-carto/issues/2016#issuecomment-249697051