search

noi-techpark / odh-mentor-otp

4 stars 8 forks source link

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

Open rcavaliere opened 5 months ago

rcavaliere commented 5 months ago

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 commented 4 months ago

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 commented 4 months ago

@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 commented 4 months ago

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 commented 4 months ago

Is this what I should be using?

rcavaliere commented 4 months ago

@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 commented 4 months ago

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 commented 4 months ago

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

leonardehrenfried commented 4 months ago

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

rcavaliere commented 4 months ago

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 commented 4 months ago

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 commented 2 months ago

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

rcavaliere commented 2 months ago

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

leonardehrenfried commented 2 months ago

@clezag I've written up a Siri example here: https://github.com/noi-techpark/odh-mentor-otp/issues/187#issuecomment-2056407918

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

leonardehrenfried commented 1 month ago

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

rcavaliere commented 1 month ago

@leonardehrenfried not yet, we are finalizing / testiing it

rcavaliere commented 1 week ago

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

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 commented 1 week ago

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

We can talk about this in our meeting tomorrow.

rcavaliere commented 1 week ago
rcavaliere commented 2 days ago

@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 commented 1 day ago

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 commented 1 day ago

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

Screenshot from 2024-07-03 15-02-10

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 commented 11 hours ago

@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 commented 10 hours ago

@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 commented 10 hours ago

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.