Analysis of using DatexII ParkingPublicationLight

leonardehrenfried commented 2 months ago

I spent some time today today to analyse if DatexII's ParkingPublicationLight is a suitable format for converting NOI's parking data.

I managed to get a JSON schema an actual example out of the Datex organisation and despite a few problems and only basic support I believe that it's format worth pursuing and perhaps extending.

I converted the schema to HTML documentation: https://leonardehrenfried.github.io/parking-publication-light-schema/DATEXII_3_D2Payload.html

There is also an example of a JSON document here: https://github.com/leonardehrenfried/parking-publication-light-schema/blob/main/Example%20Belgium%20Cities.json

Multilingual strings

One problem with DatexII that might concern South Tyrol is that multilingual strings are not supported so a parking site can only have a name/adress/note in a single language.

@rcavaliere Is it a requirement that this data is available in several languages inside OTP?

Implementation

My collegue @the-infinity has been writing and maintaining an open source project to aggregate parking data and outputting in standard formats: https://github.com/ParkenDD/park-api-v3 This is used for the German region of Baden-Württemberg's offical data publications and you can see it in action here: https://dev-ipl.mobidata-bw.de/park-api/documentation/public.html#/paths/datex2-json/get

I think the best way forward would be to use this project, improve the DatexII output so we can tell the difference between bike and car parking lots, adapt the NOI data and write an importer for OTP.

@dulvui The project maintains its own Postgres database for the parking data. Is that a problem when hosting it?

Documentation & evangelism

I haven't been able to find any real world feed with this format so I suspect that we will have to maintain the documentation and create a community around it ourself.

The support for bicycle features is quite basic so I think we might want to help extending the standard.

dulvui commented 2 months ago

@leonardehrenfried Great thank you for the analysis! An additional Postgres database would not be a problem for us. Depending on the size and how important the data is (if it is permanent data or only temporary data), we can decide between a dedicated database on Amazon RDS or a dockerized database. But in both cases it would not be a problem for us.

rcavaliere commented 2 months ago

@leonardehrenfried thanks for the contribution. Yes, the multilinguism is a (strong) requirement here in our region, so we should support it. Based on the discussion with the OTP community, we should also re-evaluate if the alternative strategy NeTEx / SIRI could be also viable. For the usage of the German project, let's discuss this together next week, in particular at the data flow we should consider. I would not have a separate database infrastructure, we should reuse what we currently have within the Open Data Hub core. In general, would be really interesting to get in contact with this project!

leonardehrenfried commented 2 months ago

@rcavaliere You have pointed out in the email thread that we could also use Siri to deliver the information. I took some time to build a Siri document and it has multi-language support and can express all the information that we need. It would like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Siri xmlns="http://www.siri.org.uk/siri" xmlns:ns2="http://www.ifopt.org.uk/acsb" xmlns:ns3="http://www.ifopt.org.uk/ifopt" xmlns:ns4="http://datex2.eu/schema/2_0RC1/2_0" xmlns:ns5="http://www.opengis.net/gml/3.2">
    <ServiceDelivery>
        <FacilityMonitoringDelivery>
            <ResponseTimestamp>2024-04-15T11:01:26.488356787+02:00</ResponseTimestamp>
            <FacilityCondition>
                <FacilityRef>noi:11242</FacilityRef>
                <Facility>
                    <Description xml:lang="DE">Bozen Mitte</Description>
                    <Description xml:lang="IT">Bolzano Centro</Description>
                    <FacilityClass>parkingBay</FacilityClass>
                </Facility>
                <FacilityStatus>
                    <Status>partiallyAvailable</Status>
                </FacilityStatus>
                <MonitoredCounting>
                    <CountingType>presentCount</CountingType>
                    <CountedFeatureUnit>vehicles</CountedFeatureUnit>
                    <TypeOfCountedFeature>
                        <TypeOfValueCode>bicycle</TypeOfValueCode>
                        <NameOfClass>bicycle</NameOfClass>
                    </TypeOfCountedFeature>
                    <Count>10</Count>
                </MonitoredCounting>
                <MonitoredCounting>
                    <CountingType>availabilityCount</CountingType>
                    <CountedFeatureUnit>vehicles</CountedFeatureUnit>
                    <TypeOfCountedFeature>
                        <TypeOfValueCode>bicycle</TypeOfValueCode>
                        <NameOfClass>bicycle</NameOfClass>
                    </TypeOfCountedFeature>
                    <Count>20</Count>
                </MonitoredCounting>
                <FacilityUpdatedPosition>
                    <Longitude>11.35689</Longitude>
                    <Latitude>46.49421</Latitude>
                </FacilityUpdatedPosition>
            </FacilityCondition>
        </FacilityMonitoringDelivery>
    </ServiceDelivery>
</Siri>

Now, wether this is really what the authors of Siri intended is up for debate but at least technically it is feasible.

noi-techpark / odh-mentor-otp