Hi Yves, > 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" >
Sounds like an interesting challenge. I've done a similar thing with Velo in Antwerp, their JSON was in better shape however and also includes capacity (calculated from data) . I used it to correct and append the existing data. I would however caution you that this data still contained errors, the locations where sometimes wrong and also the spelling of some stations had typo's , so was incorrect. The one thing that is wrong in your suggestion is to tag it with housenumbers that belong to the buildings in front of it. It's wrong for several reasons, addr:housenumber is an exact address, not an indicator of an area and cannot be used as such. Also, you will create duplicate housenumbers which except for a few circumstances are an error. It would be misuse of this key. It is also not needed as geographically , we can determine the closest address using geometric functions , aka math. That is a lot easier to maintain, when the numbers change or get expanded, this will be taken into account automatically. And lastly... ironically... it's not a house and the key is called addr:housenumber for a reason. In that sense, I believe the entire addressing is actually overkill, it can be deducted from the data around it, and it will be done like that too by tools that do this. For test, I ran my velo Q/A program again on the data in Antwerp and I see new discrepancies , I'm taking 2 random ones (it's giving me lots of warnings): ... [] - Parsing features ref '223' [] - Found OSM information tags count: 5 [scan_node] - Matching tag data to OSM.. [scan_node] - Matching velo name to OSM name.. [scan_node] - Ref + name matches. 'Red Star Line' - '223- Red Star Line' [scan_node] - Matching velo capacity to OSM capacity.. [scan_node] - Equal capacity. OK: 22+13=35 [scan_node] - Matching lat to OSM lat.. [scan_node] - Different lat. '51.2333883' - '51.2333460' [scan_node] - Matching lon to OSM lon.. [scan_node] - Different lon. '4.4030503' - '4.4031140' [scan_node] - Calculating distance .. 6 meters apart [scan_node] - Filtering lat/lon changes [] - Parsing features ref '224' [] - Found OSM information tags count: 5 [scan_node] - Matching tag data to OSM.. [scan_node] - Matching velo name to OSM name.. [scan_node] - Different name. 'Indiëstraat' - '224- Indiestraat' [scan_node] - Try fuzzy matching to OSM name.. [scan_node] - Different fuzzy name. 'Indiëstraat' - '224- Indiestraat' ... Looks like we already have a wrong spelled streetname in the data for 224 for 223, there is a 6 meter offset in the data. It took me some time to find the exact place in mapillary, https://www.mapillary.com/app/?lat=51.23364686944444&lng=4.402958666666677&z=17&focus=photo&pKey=WNkCQiefgXsWelO-XTmWGA 6 meters might sound ok, but there is more going on here. First of all, that road has recently been reworked. When I check where the node is placed right now, it's on the opposite of the place where it really is. It's in front of the Red Star Line building, not across the road. I doublechecked the velo data manually and theirs seems to be placed correctly. I've also seen the opposite, OSM being totally correct on the location and Velo just missing the ball by 25 meters... their own stations. the lesson I learned here was : Never blindly trust data until verified, Never just import without thinking about Q/A. Never assume data is accurate until tested. Big lessons sometimes ( You probably recall my URBIS Q/A efforts where I thought to have received a correct streetlist of Brussels, written correctly -I assumed- only to find out it wasn't. I stopped using my Q/A program there, If I get a correct streetlist one day I could start using it again, until then, nothing I can do.) So back to Villo, like Velo in Antwerp, they combine ref + name as the name of the stations, Velo does this to and we need to split this using the name and the ref keys, I think you split it correctly in your suggestion ,that would be consistent with other bike rentals. If you really want to include the extra information about the location, I would suggest using the 'description' tag. One issue you bring up I do frown upon: you are worried nodes are going to be put in the middle of the street ? If that is the case , the source data just sucks and we should not use it. OSM can do better here and we should not bring in mediocre data. I could probably adapt my Velo Q/A tool to work with Villo, but I just noticed that by changing their JSON, they broke my tool, I'll fix that first. Hope sharing my previous experience on this matter will help you make the best decisions. If you want to know more, let me know. Glenn _______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
