[OSM-talk-be] Renderen van addr:flats

Fri Jun 19 06:55:22 UTC 2020

Hey all,

> Hello,
>
> Le 15.06.20 à 08:23, Sander Deryckere a écrit :
> > https://www.openstreetmap.org/#map=19/50.87528/4.69102
>
> https://www.openstreetmap.org/way/499694374
> this look like a mistake :
> wiki : marking range of numbers of flats behind a door,
> but the object isn't a door, it's a building

Huh, I edited that region recently.

When importing via JOSM the addr:flats don't stand out that much because it just renders the housenumbers. I usually don't even notice until uploading. I think I'll be converting the obviously old imported addr:flats' in Leuven to "note=possible addr:flats: ... " with a FIXME.

On 16/06/2020 10:47, joost schouppe wrote:

> Sander,
> I absolutely agree with this!
> However, as much as I am a fan of CRAB, I don't really trust the subaddresses. They caused me way too many headaches when I still worked in the city of Antwerp. Anecdotally, I've surveyed one building for subaddresses near me, and there was zero correlation between what was on the post boxes and what was in CRAB. So while I agree the info is useful, I wouldn't recommend importing it. And a cursory glance at the data shows that almost all addr:flats we have, are in fact imported. See http://overpass-turbo.eu/s/V7K - the vast majority here has the tell-tale source:geometry:date tag from the GRB import; the ones I checked that haven't seem to be CRAB-imports.
>
> Op ma 15 jun. 2020 om 14:59 schreef Sander Deryckere <sanderd17 at gmail.com>:
>
>> You can do things with that data besides rendering or using it as a route location.
>>
>> If the data is more or less complete, you can process it to get the number of addresses on a street or in an area (for example, if you want to distribute a folder to the entire street).
>> Or as a postal service, you can check if that address needs a flat number, and suggest a list of flats to the users.
>>
>> Like that, I always considered the values worth to be in OSM, even if it's all on the same door/building. Though it's obviously a lot less important than housenumbers.
>>
>> Op ma 15 jun. 2020 om 14:47 schreef Marc M. <marc_marc_irc at hotmail.com>:
>>
>>> if one building have 2 entrance, it's useful to describe with entrance
>>> need to be used to reach this flats number.
>>> but having all flats number on the building or on one-only entrance,
>>> is like "to reach the inside of the building, reach the building".
>>> it's a bit like adding entrance=yes on the building to say that a
>>> building has an entrance somewhere, you don't add any real information.
>>>
>>> so at this place, I would not have added any addr:flats which would have
>>> solved the problem of rendering :) I will only use it in the case of a
>>> building with more than one entrance, and so addr:flats on the entrance
>>> does not disturb the display of addr:housenumber for the whole building.
>>>
>>> Le 15.06.20 à 13:55, Lionel Giard a écrit :
>>>> The tagging is correct, it is just not supposed to be on area from the
>>>> wiki perspective. But indeed I don't see why it is incorrect when a
>>>> building is only containing this series of flats and only one entrance ?
>>>> And if that's incorrect why are they rendering addr:flats on area and
>>>> not node ?! ^^'
>>>>
>>>> Le lun. 15 juin 2020 à 13:32, joost schouppe <joost.schouppe at gmail.com
>>>> <mailto:joost.schouppe at gmail.com>> a écrit :
>>>>
>>>> Most of this data comes from the GRB import, I would guess. So it
>>>> comes from CRAB. We use the addr:flats to map the "subaddresses".
>>>> It seems a little weird to not be able to add the subaddresses on
>>>> the same object that has the main address.
>>>> The CRAB import tool mentioned this as an optional tag, that is not
>>>> so useful for OSM:
>>>> https://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import#Optional_tags.2C_provided_by_the_tool
>>>> I would concur that the quality of the data is not good enough to
>>>> import it.
>>>> Both examples come from endless_autumn, who did a rather
>>>> quick-and-dirty GRB import - a lot of which was reverted.
>>>> The GRB-import-validator Midgard made actually flags the flats tag
>>>> as "consider removing" as well.
>>>> That said, the wiki doesn't say much about the logic of
>>>> "subaddresses", maybe we shouldn't use the addr:flats tag -at all-
>>>> for subaddresses?
>>>>
>>>>
>>>> Op ma 15 jun. 2020 om 09:22 schreef Sander Deryckere
>>>> <sanderd17 at gmail.com <mailto:sanderd17 at gmail.com>>:
>>>>
>>>> Hmm,
>>>>
>>>> it seems indeed that, according to the wiki, this should not be
>>>> placed on areas.
>>>> However, I expect that in all these cases, all flats are
>>>> accessible behind the same door.
>>>> So correcting the tag will have the same effect.
>>>>
>>>> Op ma 15 jun. 2020 om 09:12 schreef Marc M.
>>>> <marc_marc_irc at hotmail.com <mailto:marc_marc_irc at hotmail.com>>:
>>>>
>>>> Hello,
>>>>
>>>> Le 15.06.20 à 08:23, Sander Deryckere a écrit :
>>>> > https://www.openstreetmap.org/#map=19/50.87528/4.69102
>>>>
>>>> https://www.openstreetmap.org/way/499694374
>>>> this look like a mistake :
>>>> wiki : marking range of numbers of flats behind a door,
>>>> but the object isn't a door, it's a building
>>>>
>>>> maybe osm.carto should avoid to render tagging mistake and
>>>> target
>>>> only node and maybe only with entrance or door tag
>>>>
>>>> Regards,
>>>> Marc
>>>
>>> _______________________________________________
>>> Talk-be mailing list
>>> Talk-be at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>> _______________________________________________
>> Talk-be mailing list
>> Talk-be at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
> --
>
> Joost Schouppe
> [OpenStreetMap](http://www.openstreetmap.org/user/joost%20schouppe/) | [Twitter](https://twitter.com/joostjakob) | [LinkedIn](https://www.linkedin.com/pub/joost-schouppe/48/939/603) | [Meetup](http://www.meetup.com/OpenStreetMap-Belgium/members/97979802/)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20200619/85299eeb/attachment.htm>