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 notifications@github.com:

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

[andrewshadura]

I’m not sure quite why this has got closed — the justification doesn’t seem to take into account the actual usage of the numbers in the countries they’re in use.

The trouble with setting addr:housenumber to both conscription number and street number is that conscription numbers are usually long and they repeat on every entrance: whereas they can be rendered in a more concise and visually pleasing way: (never mind the contrast, this map is for hiking) This is achieved by this code: https://github.com/FreemapSlovakia/freemap-mapnik/blob/6ebfb5676cae69c16fe91028c80dca998d017044/style/layers.js#L601. Obviously, this way of rendering doesn’t clutter the map nearly as much. It is possible currently to achieve something similar by tagging housenumbers using this scheme: However, some people don’t like this way because it seems superficially like tagging for the renderer, so it would ultimately be better to teach renderers about conscription numbers.

[imagico]

I’m not sure quite why this has got closed

That has been explained above - addr:conscriptionnumber is a regional specialty used in two countries only and no suggestion has been made how to render it that would not negatively affect mapper feedback elsewhere by creating the same visual results for semantically very different taggings.

Keep in mind almost all the features with addr:conscriptionnumber have a addr:housenumber tag.

My understanding of the documentation on the wiki:

https://wiki.openstreetmap.org/wiki/Key:addr:streetnumber https://wiki.openstreetmap.org/wiki/Key:addr:conscriptionnumber

is that the tagging scheme suggested is based on transporting semantic information in the identity of values under different keys, i.e. on a feature with identical values in addr:streetnumber and addr:housenumber, addr:housenumber has a specific meaning while on a feature with identical addr:conscriptionnumber and addr:housenumber, addr:housenumber has a different distinct meaning. That is a convoluted and error prone tagging system we most certainly don't want to support.

Personally i would consider rendering addr:conscriptionnumber in addition to addr:housenumber if this is done in a distinct styling which reliably allows seeing which is which.

[andrewshadura]

That has been explained above - addr:conscriptionnumber is a regional specialty used in two countries only and no suggestion has been made how to render it that would not negatively affect mapper feedback elsewhere by creating the same visual results for semantically very different taggings.

I won’t affect anyone not using these tags.

Keep in mind almost all the features with addr:conscriptionnumber have a addr:housenumber tag.

As I explained above, addr:housenumber is not guaranteed to have data from both other tags.

on a feature with identical values in addr:streetnumber and addr:housenumber, addr:housenumber has a specific meaning while on a feature with identical addr:conscriptionnumber and addr:housenumber, addr:housenumber has a different distinct meaning.

No, you’re misunderstanding this. What I’m suggesting is that the renderer renders addr:streetnumber only when both addr:streetnumber and addr:conscriptionnumber are present; it would ignore addr:housenumber in this case. Similarly, if addr:conscriptionnumber is present, but not addr:streetnumber, render that instead. If none of the two is tagged, render addr:housenumber. The tag addr:housenumber has no useful value when the other tags are present.

[imagico]

No, you’re misunderstanding this. What I’m suggesting is that the renderer renders addr:streetnumber only when both addr:streetnumber and addr:conscriptionnumber are present; it would ignore addr:housenumber in this case.

I understood you perfectly fine.

We render addr:housenumber in the sense of how it is used in OSM almost worldwide as the main numerical/alphanumerical code that is assigned, often signed and practically used to uniquely identify an address to someone who wants to find that address. As such we regard it useful for the map user and therefore display it unless there is something else with higher priority in the map blocking the address label.

What you suggest is to ignore addr:housenumber in case of the presence of other tags - evidently because in those cases it is apparently not the main numerical/alphanumerical code that is assigned, often signed and practically used to uniquely identify an address - or because it is a duplicate of a number also tagged in another tag - which is considered the primary field to store this data, contrary to mapping conventions in other parts of the world. That is something we most certainly will not support.

[andrewshadura]

As such we regard it useful for the map user and therefore display it unless there is something else with higher priority in the map blocking the address label.

This is exactly this case here.

because it is a duplicate of a number also tagged in another tag - which is considered the primary field to store this data, contrary to mapping conventions in other parts of the world.

On the contrary, that would allow to keep unstructured house number in the house number field, but be more smart on rendering it to avoid cluttering the map.

I understood you perfectly fine.

Apparently not, unfortunately 😞

[andrewshadura]

There is absolutely no downside in implementing this proposal, but the benefit would be better usability of the map to the users.

Just because you don’t like the local addressing scheme, it doesn’t mean those addresses are going to disappear, or people will stop mapping them. By not rendering them appropriately we’re just making lives of users harder than necessary.

[imagico]

I think i have explained my reasoning quite clearly. And please don't make assumptions on my personal dislikes - i have not expressed anything in that regard. I don't have a qualified opinion on what is the best way to tag the main unique assigned numerical identifiers in addresses. I just look at what the practice in doing so is in OSM. And that is very clearly through addr:housenumber. And we try to support mappers in consistent use of tags, that is one of the primary purposes of this style - see here. That means we will render addr:housenumber whenever it is tagged and not hide it because there is a different tag supposedly indicating that it (and not addr:housenumber) is the main numerical code that is assigned and used to uniquely identify the address. That is literally the fragmentation of tag use we want to not support.

If there are other, additional unique numerical identifiers in addresses in some parts of the world that are in practical use and consistently tagged - i would be open to ideas of rendering them in a way that clearly indicates that they are different in nature from the main identifier tagged in addr:housenumber. But in addition and in a discernible styling, not in a way that the map user has to wonder if this is addr:housenumber or something else.

If you want to change my view of this you would have to provide evidence and reasoning. Unsubstantiated claims that it would be smart to think differently and that there would be no downsides to what you suggest are not.

[andrewshadura]

But in addition and in a discernible styling, not in a way that the map user has to wonder if this is addr:housenumber or something else.

You say so, but addr:housename, addr:housenumber and name are rendered exactly the same way. And house names are mapped much less consistently than conscription numbers. And conscription numbers are, in fact, house numbers, they’re in a separate tag because they can be used in a multitude ways combined to the street house numbers, and they’re difficult to support when they’re not separate. But well.

I guess, with that sort of reasoning, openstreetmap.org should have a disclaimer in big red letters: This is not a map; this is a visualisation of a geo database intended for debug purposes only. Usage for navigational purposes at your own risk only!

It also fails four of six of the main goals stated on the page your linked to. But fine, I don’t have much energy to argue and try to prove you wrong.