Inconsistency on virtual station

[Yaronn44]

Greetings,

I noticed what seems to be an inconsistency in the definition of station_information.json.
For the field is_virtual_station we have:

true - The station is a location without smart docking infrastructure. the station may be defined by a point (lat/lon) and/or station_area (below).

But we also have for the field station_area:

If lat/lon and station_area are both defined, the lat/lon is the significant coordinate of the station

But it is currently not possible to set lat/lon to null. This mean that even if we want to define only station_area, we are forced to define lat/lon that become the significant coordinate.

In my opinion, the solution is to be able to set lat/lon to null, because even if it possible to define a virtual station with only a single coordinate it should also be possible to defined a virtual station with only a set of coordinates.

You'll also need to make sure that either lat/lon or station_area is supplied and not null.

Is your potential solution a breaking change?

• Yes
• No
• Unsure

[tdelmas]

It is a breaking change, as it will break consumers that rely on lat/lon.

[richfab]

Hello Ivan,

That's a good point, there is an inconsistency. Thank you for flagging.

As you pointed out, the lat/lon fields are always REQUIRED while the is_virtual_station field indicates that lat/lon are OPTIONAL when the station_area field is defined.

I could imagine that data consumers would find it more convenient to have the lat/lon fields always defined, rather than having to calculate single point coordinates from station_area MultiPolygons.

For this reason, my recommendation is to remove the part that says "the station may be defined by a point (lat/lon) and/or station_area (below)." from the is_virtual_station definition. This solution would not be a breaking change.

Curious to hear what you and the community thinks.

Thanks

[sven4all]

Maybe a clarification works better. Having a station_area + the centroid point of the station area (https://turfjs.org/docs/api/centroid) would be a nice to have. Without breaking the currrent spec.

This will be handy to show a marker when you are a little bit zoomed out for example. An example implementation of that you can find here https://dashboarddeelmobiliteit.nl/map/beleidshubs?phase=active&gm_code=GM0014&visible=hub-active&visible=verbodsgebied-active (try to zoom in on a hub icon).

[futuretap]

In Where To?, we rely on lat/lon so we'd like to keep it. We might support station_area in the future and would prioritize it, at least for high zoom levels as @sven4all suggested.