[OSM-talk-be] Importing Villo! API data

Mon Oct 16 04:52:45 UTC 2017

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
<bxl-forever at linuxmail.org> 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 <cednospam at gmail.com> 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
>> 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