Hi,
The Flemish MOW department has asked if we could provide info about the new Hoppin points in OSM. Basically, Hoppin points are places that facilitate going from one transportation mode to the next. For example there might be at least two of: bus stop, train station, bicycle parking or rental, car sharing, …
These are clearly branded with the Hoppin logo, which always should feature a sort of central column (information point). The current idea is to simply import these columns as points. In the future, the various modes that belong to the Hoppin point could be joined in a site relation.
There is a WFS server where all the data can be downloaded and easily filtered based on the status (we only want the ones that actually exist):
A proposed tagging schema is available here. I would definitely add something like ref:hoppin with the identifier from the official source, to make future automated edits easier.
EDIT: this proposal for amenity=mobility_hub seems like a very good fit
Since it is just the import of nodes, there are hardly points mapped yet (for lack of a data model until now), and the data is very new (and I’ve been told quite precise), this could be a relatively easy import. I propose a simple data conversion script and then a bulk import with JOSM.
A large portion of the ‘Hoppinzuilen’ is of the digital type (see image). I believe information=map to be an incorrect tag to describe these columns. I think information=terminal is a better fit for these electronic, interactive points. Especially given the fact that the interactive signs display realtime bus information.
Secondly, are you sure about the quality of the data? I know of a Hoppinzuil that is at least a couple of months old, but is not in the dataset. Also, there seem to be some points which don’t have their type correctly set.
Thanks for the feedback!
Regarding data quality - everyone always thinks their data is perfect, I only have the owner’s word on it that the data quality is good. If you could send me the specific cases (PM is OK), then I can send it to the data owner for some feedback.
Makes sense. According to the city of Leuven, their Hoppin locations have been funded via an European initiative (Shared & Digital Mobility Hubs ShareDiMobiHub | Interreg North Sea). And is all about ‘mobility hubs’.
It would be good to get in touch with the OSM’s of Norway, Denmark and The Netherlands (and even others) to align. These countries also participate in this European project.
The dataset has points (hoppin:hoppinzuil) & polygons (hoppin:hoppinpunt). The points are the visible infrastructure, the polygons show the zone with related services and has attribute info on local services.
The data in OSM should be either a point or a site relation (many of those already mapped in Germany, two in Belgium).
I’m going to ignore the polygons for now. For the points, I would process them like this:
hoppin_official<-hoppin_official %>%
mutate(
"ref:hoppin_column"=ID,
name=Hoppinpunt,
network='Hoppin',
"network:wikidata"='Q124310711',
amenity='mobility_hub',
fixme='imported from official source, geometry might be off. Remove this fixme when location improved',
tourism='information',
information=case_when(
Type=='Interactief' ~ 'terminal',
Type=='Analoog (grote versie)' | Type=='Analoog (kleine versie)'~'board',
TRUE ~NA_character_
))
Then I’ll compare that data to OSM data that already has the ref:hoppin_column value and delete those from the set. Next I’ll look at points that have amenity=mobility_hub or name~hoppin but not that tag, and deal with those manually. Finally, if there is a site relation, I’ll add the newly created points to the sites. Here’s an example for the two sites that were already mapped:
Maybe in these cases, the “column” node should lose the amenity=mobility_hub tag?
I noticed the two hoppin columns already mapped had information=terminal, but were supposadly analog in the official data…
There are currently 4 open notes regarding locations of Hoppin points: note 3909000, note 3909006, note 3909007 and note 3909016. They were created in September 2023. However, at none of the locations, any of the objects relating to the Hoppin import are present. Does this mean Hoppin points were proposed at these locations, but not actually constructed, or could there be a problem with the import and/or the accuracy of the data here?
In neither of the layers (existing columns & polygons that include planned infrastructure) is there anything visible at any of these locations. I guess we can ask the data source if it’s normal that some folks know about a planned location but it’s not in the data yet.
I manually created Zeebrugge Strandwijk, even though the panel has been there at least since July 2024.
I moved the imported Blankenberge Station by 65 meters and around the corner of the station building. But the physical panel has a map, and IIRC it has its own location marked, and correctly so. So when they’re making the map for the panel, they don’t update their dataset with the correct location?
Op de plaats van punt Node: Achel Nieuwe Kerk (12328588759) | OpenStreetMap is er op de Mapillary van enkele weken geleden geen Hoppin te zien. Moet dat punt dan gewist worden of zullen die ontbrekende punten nog geïnstalleerd worden?
Ik zou het zeker niet gewoon wissen, want dan gaan we het bij een update gewoon weer toevoegen. Ik zou er een proposed:amenity van maken en voor de rest de tags behouden. Misschien een note aan toevoegen met wat context, of een fixme om het later nog na te kijken.
I just discussed all the feedback with Hoppin team:
those Notes of planned infrastructure are known to the team. They were surprised that this is not visible in the public data - but anyway they know of several thousand points and in the public data there is only a few hundred. In any case these notes can be closed and there is no data issue.
Zeebrugge: yes, it is possible that the data flow is this slow.
Blankenberge: yes, some of the data flows are this bad. Both issues should start getting solved now, because one of the middlemen will be taken out of the process
Achel: that point has been known in their DB from much before the images were made. So this is clearly an error. They will dig into it, to see where it went wrong.
About a third of the data has already been improved from a secondary database of higher quality. So I should look into how many imported points have moved in the source data by now. New data should be of higher quality from now on.
