I'm not sure whether it is a good idea to "copy" the address of a house to another object, that does not really have that address. As the original address information is "face 35-39 / tegenover 35-39", the bicycle rental place should not have addr:housenumber=35-39 imho
m. On Sun, Oct 15, 2017 at 6:57 PM, Yves bxl-forever <[email protected]> wrote: > Hello, > > In the past weeks I have also wanted to do some cleanup on Villo! stations > and it’s a fact that there still quite a lot of work to be done. > > Just a few thoughts about the idea of bulk data imports because this is what > gave us really "ugly" nodes sometimes. > > The name itself is a problem because what they present as the name is > actually a string that concatenates the ID of the station, the name and its > address. This is why tagging this as "official_name" does not seem to make > any sense. > > Their JSON dataset usually looks like this: > > "name":"076 - PLACE VAN MEENEN/VAN MEENENPLEIN", > "address":"PLACE VAN MEENEN/VAN MEENENPLEIN - AV PAUL DEJAER (FACE 35 - 39) / > PAUL DEJAERLAAN (TEGENOVER 35 - 39)" > > > And we must translate it as such in our OSM nodes: > > ref=76 > name="Place Van Meenen - Van Meenenplein" > name:fr="Place Van Meenen" > name:nl="Van Meenenplein" > addr:street="Place Maurice Van Meenen - Maurice Van Meenenplein" > addr:housenumber="35-39" > > > It’s probably feasible to parse the fields automatically and make something > that looks clean. > But I am not sure that the street name will always match (see example here, > official name has "Maurice" somewhere and our parsing script will not guess > it unless you feed it with a list of all streets). > > About missing names in one language, this is tricky: normally we should stick > with the official name given by the operator. But another approach will be > that if we know of an official translation (because it is the same name as > the street or even a bus stop nearby, or a building) it should be used. And > I agree that we should fix typos without asking, like in your example. > > Another problem is that the longitude and latitude fields must be checked to > avoid putting stations in the middle of an intersection or inside a building. > > > In summary, I will recommend a safer approach, i.e. extracting a list of > missing stations, and add them one by one manually, after checking whether > the data looks fine. > But it will be nice to hear the thoughts of other members of the community. > > Have a nice day. > > Yves > > > > On Sun, 15 Oct 2017 13:48:42 +0200 > CedB12 <[email protected]> wrote: > >> Hello all, >> >> Lately I have been looking at the Villo! dataset from the JCDecaux API >> at [1], which is released under the Etalab Open License (see also [2]). >> I want to consult the community about the use of this data to improve >> the tagging of the stations we have already mapped. I would also like to >> discuss a potential import of the hundred or so stations that are >> reported in the API but have not been mapped yet in OSM. >> >> My priority is to fix the tagging of station names and reference >> numbers, which are often wrong or missing in the already-mapped >> stations. I am aware of a few quality issues in the names reported by >> the API (which, as far as I know, are actually the names reported at the >> stations themselves), so this cannot be a fully automated process. As >> far as ref tags are concerned, only 25 existing station nodes do not >> match the API. I have not pushed any change yet in case this thread >> brings up an objection to the use of this API data. >> >> More importantly, given the quality issues in the API names, we would >> need to discuss how exactly we want to tag names vs. what the "official" >> names are. >> >> To give you a quick example of what kind of problems we can find in the >> API, consider that one station is named "342 - MAISON COMMUNALE DE >> BERCHEM ST AGHATE". Like all other stations, the name is in all-caps. >> This one in particular contains a misspelling: the commune is actually >> spelled "Berchem-Ste-Agathe". Also, unlike other stations, this one has >> no official Dutch name, and it is not clear to me whether we should >> provide our own translation in the name and name:nl tags. >> >> I actually got a little bit ahead of myself and had prepared a diary >> entry draft as well as a more detailed and specific email for this >> mailing list, but I now realize that unloading all of this at once might >> have felt a bit forceful. So before I go into the details of all the >> quirks in the API data and formulate a general proposal for tagging, I >> wanted to take a more open-ended approach and ask if anyone had anything >> to share regarding our mapping and tagging of Villo! stations. I am also >> interested in your thoughts on how we should tag the station I gave >> above as an example (in terms of name, name:fr, name:nl, and maybe other >> kinds of name tags like official_name). >> >> But before that, I would like to make sure that it is OK to import >> Etalab-licensed data, because otherwise this effort will be pointless. I >> assume it must be fine because the license states to be compatible with >> "any licence which requires at least the attribution of the « >> Information »" [3], including the Open Government License which is in >> turn listed on the OSM wiki page on ODbL compatibility [4]. How are the >> requirements of the license (attribution by source name + date + URL) >> handled, though? >> >> Also, does an operation of this scale (tagging a subset of 200 existing >> nodes and possibly importing another 100) require that I follow the >> import guidelines? >> >> Thanks, >> >> Cédric >> >> >> [1] https://developer.jcdecaux.com/ >> [2] http://opendatastore.brussels/en/dataset/villo >> [3] https://developer.jcdecaux.com/files/Open-Licence-en.pdf >> [4] https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility >> >> _______________________________________________ >> 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 _______________________________________________ Talk-be mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-be
