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. <[email protected]>: > 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 <[email protected] > > <mailto:[email protected]>> 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 > > <[email protected] <mailto:[email protected]>>: > > > > 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. > > <[email protected] <mailto:[email protected]>>: > > > > 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 > [email protected] > https://lists.openstreetmap.org/listinfo/talk-be >
_______________________________________________ Talk-be mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-be
