EPIC: As Open Data Hub manager I would like to connect the new v2 OTP instance with all currently available adapters (other mobility services)

[rcavaliere]

• Bike sharing services
• Car sharing service
• Parking services (on-street)
• Parking services (off-street)

E-mobility services won't be part of the OTP routing engine

Current end-points available:

Bike sharing Bolzano, standard version 2.1: https://gbfs.otp.opendatahub.com/bz/2.1/gbfs.json
Bike sharing Bolzano, standard version 1.0: https://gbfs.otp.opendatahub.com/bz/1/gbfs.json
Bike sharing Merano, standard version 2.1: https://gbfs.otp.opendatahub.com/me/2.1/gbfs.json
Bike sharing Bolzano, standard version 1.0: https://gbfs.otp.opendatahub.com/me/1/gbfs.json
Bike sharing Papin, standard version 2.1: https://gbfs.otp.opendatahub.com/papin/2.1/gbfs.json
Bike sharing Papin, standard version 1.0: https://gbfs.otp.opendatahub.com/papin/1/gbfs.json
E-charging stations: https://charger.otp.opendatahub.com/charger/stations.json
Parking: https://parking.otp.opendatahub.com/parking/all.json
Car sharing: https://carsharing.otp.opendatahub.com/carsharing/stations.json
On-demand: https://drt.otp.opendatahub.com/drt/all.json

[rcavaliere]

#Decision: no focus on e-charging stations + on-demand. On-demand will be considered when new data feeds will be available.
For parking, let's consider the right standard API

[leonardehrenfried]

@rcavaliere The car sharing feed is in a format that is close to GBFS but not quite. I would suggest to convert it to GBFS rather than teaching OTP how read this custom format.

Would you like me to take this on job? If you do, then @hbruch is the maintainer of https://github.com/mobidata-bw/x2gbfs which takes any data source and outputs GBFS. I think it would be a good idea to use it.

@dulvui what would be the correct way to go about this? I can already see some code in the repo that takes some source and converts it into the quasi-GBFS. However, I cannot figure out where this process actually gets its source data. Can you help me out here? Perhaps we could also have a short meeting to talk about it together.

[leonardehrenfried]

I have now found the source of the data:

https://mobility.api.opendatahub.com/v2/flat%2Cnode/CarsharingStation?limit=500&offset=0&shownull=false&distinct=true
https://mobility.api.opendatahub.com/v2/flat%2Cnode/CarsharingCar?limit=500&offset=0&shownull=false&distinct=true

[leonardehrenfried]

Is this what I should be using?

[rcavaliere]

@leonardehrenfried yes these are the Open Data Hub end-points that you need as input for the GBFS conversion. Of course we can improve the input to OTP2, if you think to be better to do so! Can you please make first an estimation for this extra activity?

[leonardehrenfried]

Well, the other option would be to change OTP but I don't think it's a good use of my time as the GBFS code is much better maintained.

I estimate that it will take me 2 days to convert it to GBFS.

[leonardehrenfried]

I'm also happy to revisit the topic at our next sprint meeting.

[leonardehrenfried]

If you want to take a look at the bicycle GBFS data, here is a GraphQL query: http://tinyurl.com/22jspunh

[rcavaliere]

Well, the other option would be to change OTP but I don't think it's a good use of my time as the GBFS code is much better maintained.

I estimate that it will take me 2 days to convert it to GBFS.

That's fine, please proceed with this activity!

[leonardehrenfried]

I have a very early preview version of a Carsharing Südtirol GBFS feed available at: https://leonard.io/gbfs/noi/gbfs.json

It has a quite a few limitations but it will already be good enough for importing into OTP. Lets discuss more in the meeting.

[dulvui]

Car sharing gbfs is now available here https://carsharing.otp.opendatahub.testingmachine.eu/noi/gbfs.json

[rcavaliere]

For parking (car / bike): let' use the NeTEx / SIRI interfaces that we are currently developing with @clezag

[leonardehrenfried]

@clezag I've written up a Siri example here: #187 (comment)

The static parts like the name, coordinates and total number of spaces can also be moved to a Netex feed.

[leonardehrenfried]

@rcavaliere @clezag Is there a Netex/Siri feed parking data available yet?

[rcavaliere]

@leonardehrenfried not yet, we are finalizing / testiing it

[rcavaliere]

@leonardehrenfried finally we have the first consolidated interfaces for parking data in NeTEx and SIRI format.

• NeTEx: https://sta-netex.opendatahub.testingmachine.eu/netex/parking
• SIRI: https://sta-netex.opendatahub.testingmachine.eu/siri/fm

Please start have a look so that we can eventually discuss some technical points during our next meeting.

If you need some kind of specification on the meaning / content of the different fields, let me know

[leonardehrenfried]

That looks already really great, but I do have a few questions:

• since multiple languages were a strong requirement, I wonder why no names are translated
• I can't see any information if something is a car or bicycle parking lot. I suspect this information should go into ParkingVehicleTypes
• what is the difference between principalCapacity and totalCapacity
• why is the Siri feed formatted as JSON but the Netex one is XML?

We can talk about this in our meeting tomorrow.

[rcavaliere]

• Add multilingual information for parking (i.e. name)
• It is ParkingVehicleTypes. There is a bug in the NeTEx export, to be fixed
• Please consider totalCapacity. This refers to the current capacity, principalCapacity is related to a nominal capacity (could be outdated)
• Because it's compliant with national SIRI specification. Provide the reference specification.

[rcavaliere]

@leonardehrenfried open points have been internally shared.
As far as the necessity to have a SIRI-LITE in JSON format, I attach here a reference national specification document

240620_RAP - Specifiche interfacce dati dinamici.pdf

As far as the multilinguism is concerned, I have to check better when I am back. The usage of AlternativeTexts in the national profile was not foreseen and if I remember well we omitted this in order to pass the validation. My suggestion is therefore to work at the beginning with just one field Name

[leonardehrenfried]

About multiple languages: you don't need to use AlternativeText. You can set the name like this:

<Parking id="IT:ITH10:Parking:1930" version="1">
	<Name xml:lang="IT">Bressanone, stazione di Bressanone</Name>
        <Name xml:lang="DE">Brixen Bahnhof</Name>
	<Centroid>
		<Location>
			<Longitude>11.650457</Longitude>
			<Latitude>46.711594</Latitude>
		</Location>
	</Centroid>
	...
</Parking>

cc @clezag

[rcavaliere]

@leonardehrenfried not sure if this is compliant with the standard.
I know this type of representing multilingual information is NeTEx-compliant:

As said, however, I need to check if we multilinguism is supported by the national platform. If not, it would be better to first to amend the national NeTEx specification and then add this, because otherwise I am afraid that our NeTEx export won't be validated.

[leonardehrenfried]

@rcavaliere Do you want to use both the parking lots from OSM and Netex in your OTP installation or just the Netex ones? If you have both it's likely that you have duplicates in OTP.

[rcavaliere]

@leonardehrenfried the parking areas in the NeTEx export are at present a very small number with respect to the ones available in OSM. I would recommend to use OSM for the main source of data for "static" parking information. The NeTEx / SIRI should be considered for the parking areas for which we have real-time data. However, the mapping between the two sources of data could be challenging. Would such approach in your view be feasible?

[leonardehrenfried]

Yes, it is feasible if you can live with some duplicates. On a map you might then see two parking lots very close to each other where one has realtime data and the other one doesn't. Is this acceptable to you?

An alternative to this would be to ingest the OSM data into your Netex component and make it contain all parking lots, even those that don't have realtime.

[rcavaliere]

@leonardehrenfried having such duplicates is not ideal, I would avoid this. My idea would be e.g. to feed in OSM some attributes like e.g. a Global ID for the parking areas that are part of our NeTEx exports. These parking areas that have such Global IDs are part of the SIRI stream, i.e. we have real-time values that OTP can consider. In other words, the ideal use case would be:

• static parking information: reference source is OSM. In this way all possible P&R combinations (static) can be computed and offered to the end-users
• real-time parking information: such parking areas are present in OSM and enriched with proper fields (e.g. Global IDs) in OSM. OTP considers the SIRI stream to consider real-time values for just these parking areas. OTP considers the real-time occupancy of the parking areas when suggesting P&R combinations (i.e. if limited parking availability, this combination is not suggested).

[leonardehrenfried]

I'm not sure I understand every detail of your idea but generally I think that could work.

Should we discuss the approach in detail in the next meeting?

[rcavaliere]

I'm not sure I understand every detail of your idea but generally I think that could work.

Should we discuss the approach in detail in the next meeting?

@leonardehrenfried ok, let's discuss this together!