errors/questions for sw_stuttgart mapping doc

[ThorstenFroehlinghaus]

The mapping document https://github.com/binary-butterfly/ocpdb/blob/main/docs/mapping/sw_stuttgart.md for the mapping between https://new-poi.chargecloud.de/SW-Stuttgart and https://api.mobidata-bw.de/ocpdb/api/public/v1/locations?source=sw_stuttgart needs some clarifications and changes:

https://github.com/binary-butterfly/ocpdb/blob/main/docs/mapping/sw_stuttgart.md#source-location:

id is mapped to location.uid, not to location.id

country is not transformed to an OCPI 3 digit language code. Is the mapping wrong or the mapping documentation?

owner is not mapped to location.operator

https://github.com/binary-butterfly/ocpdb/blob/main/docs/mapping/sw_stuttgart.md#source-stadtwerkestuttgartcoordinates:

latidute/longitude are mapped to lat/lon, not to latidute/longitude

https://github.com/binary-butterfly/ocpdb/blob/main/docs/mapping/sw_stuttgart.md#source-evse:

uid is not mapped to location.id. it is not mapped at all. should it be mapped?

id is mapped to evse.uid, but not to evse.evse_id

https://github.com/binary-butterfly/ocpdb/blob/main/docs/mapping/sw_stuttgart.md#source-connector

is is mapped to connector.uid, not to connector.id

[the-infinity]

id is mapped to location.uid, not to location.id
uid is not mapped to location.id. it is not mapped at all. should it be mapped?
id is mapped to evse.uid, but not to evse.evse_id
id is mapped to connector.uid, not to connector.id

Hmm. Correct, but also an interesting point, where the OCPDB was never super-specific about the (u)id mapping, but I guess it's the moment to clear this. We somehow have the issue that the (u)id in OCPI cannot be guaranteed to be unique, because different data sources can have the same uid. I do see two solutions:

1. prefix (u)ids with the source uid. Has a quite high risk of breaking the length of (u)id: it's usually 36, and a lot of platforms use 36 characters by using UUIDs. When we prefix a UUID, it's not OCPI compliant any more.

2. introduce the non-standard-compliant original_(u)id as we do in ParkAPI, and output an own (u)id. Then we can output a proper (u)id generated by us, and therefore be sure that it's max 36 characters and unique. Extension with non-standard-parameters gets compliant with OCPI 2.3, which is not released yet.

I slightly prefer the second option. What do you think, @ThorstenFroehlinghaus?

owner is not mapped to location.operator

Ups. Copy paste issue.

latidute/longitude are mapped to lat/lon, not to latidute/longitude

Uh, that's an issue at the output, the current output is not OCPI compliant. The documentation is correct, just not the actual output: https://api.mobidata-bw.de/ocpdb/documentation/public.html#/schemas/Location . I do output both now, and will remove lat / lon after a migration period.

country is not transformed to an OCPI 3 digit language code. Is the mapping wrong or the mapping documentation?

That was also a general issue in the OCPI output compatibility.

Except for the (u)id question, everything is resolved in #82

[ThorstenFroehlinghaus]

Hi Ernesto, does the uid attribute in https://api.mobidata-bw.de/ocpdb/api/public/v1/locations need to be unique? If we map the id attribute of a source to our uid attribute, then I would expect that the combination uid,source needs to be unique, but not the uid attribute on its own. The id attribute in https://api.mobidata-bw.de/ocpdb/api/public/v1/locations is our own attribute, so we can generate a unique id, right? Regards, Thorsten Thorsten Fröhlinghaus Dr. Technischer Leiter - Team Mobilitätsdaten & Innovationen T +49 711 23991-1138 @ ***@***.*** F +49 711 23991-23 NVBW - Nahverkehrsgesellschaft Baden-Württemberg mbH Wilhelmsplatz 11 70182 Stuttgart www.nvbw.de<http://www.nvbw.de/> [cid:NVBW_a90eddca-c536-413f-a211-e09ee1a4f760.jpg] Hinweise zur Datenverarbeitung nach der DSGVO erhalten Sie hier.<https://www.nvbw.de/datenschutz> Geschäftsführung: Volker M. Heepen, Monika Burkard ++ Aufsichtsratsvorsitzender Berthold Frieß ++ Amtsgericht Stuttgart HRB Nr. 17102 Von: Ernesto Ruge ***@***.***> Gesendet: Freitag, 24. Januar 2025 09:10 An: binary-butterfly/ocpdb ***@***.***> Cc: Fröhlinghaus, Thorsten ***@***.***>; Mention ***@***.***> Betreff: Re: [binary-butterfly/ocpdb] errors/questions for sw_stuttgart mapping doc (Issue #81) id is mapped to location.uid, not to location.id uid is not mapped to location.id. it is not mapped at all. should it be mapped? id is mapped to evse.uid, but not to evse.evse_id id is mapped to connector.uid, not to connector.id Hmm. Correct, but also an interesting point, where the OCPDB was never super-specific about the (u)id mapping, but I guess it's the moment to clear this. We somehow have the issue that the (u)id in OCPI cannot be guaranteed to be unique, because different data sources can have the same uid. I do see two solutions: 1. prefix (u)ids with the source uid. Has a quite high risk of breaking the length of (u)id: it's usually 36, and a lot of platforms use 36 characters by using UUIDs. When we prefix a UUID, it's not OCPI compliant any more. 2. introduce the non-standard-compliant original_(u)id as we do in ParkAPI, and output an own (u)id. Then we can output a proper (u)id generated by us, and therefore be sure that it's max 36 characters and unique. Extension with non-standard-parameters gets compliant with OCPI 2.3, which is not released yet. I slightly prefer the second option. What do you think, @ThorstenFroehlinghaus<https://github.com/ThorstenFroehlinghaus>? owner is not mapped to location.operator Ups. Copy paste issue. latidute/longitude are mapped to lat/lon, not to latidute/longitude Uh, that's an issue at the output, the current output is not OCPI compliant. The documentation is correct, just not the actual output: https://api.mobidata-bw.de/ocpdb/documentation/public.html#/schemas/Location<https://atpscan.global.hornetsecurity.com?d=1CHc0YCRkk2S-g-d4ElR4KkJsxnZpQYc8ZaVc6OkAIs&f=ltJSWgxBeL1D5lNe7aWrcVnnC8HG6mXr7MiTACOeyNjJ0-2G1-U2GS2oKzIK3Q3m&i=&k=sVM5&m=GfjybMnunhod_KvNDzcHyU7IBt3y7z5ioa0HzDpe6x9TT6kOOF0X36kYhJJop05dfbEh1wp_0caKJ9t0pg57lM3SBrOG2HZgCSwEjs-MICTI1gtzxApFBgtnhxl3zTdK&n=N7A3b-z6-SE2dJNm6L9Nlu2PZux3nQY5PG8M4a6lBDT-8-xnoVUuGvv0IQbh13XC&r=hGdSPtMVJvnseo9q1CHka6G08aVZwZyAq6zU6QoxKoxj35reVbQsRDA2MFyz6ne0&s=e85964be6d5fb2712b1ccccd998761ebcea2105025998b9dfd90e3124737da1d&u=https%3A%2F%2Fapi.mobidata-bw.de%2Focpdb%2Fdocumentation%2Fpublic.html%23%2Fschemas%2FLocation> . I do output both now, and will remove lat / lon after a migration period. country is not transformed to an OCPI 3 digit language code. Is the mapping wrong or the mapping documentation? That was also a general issue in the OCPI output compatibility. Except for the (u)id question, everything is resolved in #82<#82> — Reply to this email directly, view it on GitHub<#81 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A4X6PTMGWXGN6LXPJ2ZW4A32MHYODAVCNFSM6AAAAABVZACALOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJRHEYDQNRXGU>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[the-infinity]

does the uid attribute in https://api.mobidata-bw.de/ocpdb/api/public/v1/locations need to be unique?

It's not allowed according to OCPI. If we keep within standards, we have to remove it. Instead, I would say that we backport the upcoming custom attribute functionality OCPI 2.3 and call it original_id, to make clear that this is the unique id from our data source. This also applies to source: this is not part of the OCPI standard.

Holger suggested that it makes sense to support a strict URL parameter, to filter all non OCPI 2.2.1 compliant values. I like that idea, because it brings two worlds together: the need of additional fields which are required on a data gathering platform, and the ability to output strict OCPI.

The id attribute in https://api.mobidata-bw.de/ocpdb/api/public/v1/locations is our own attribute, so we can generate a unique id, right?

Yea, this is unique already (and has the wrong type, it has to be a string).

[ThorstenFroehlinghaus]

The backport solution and the strict attribute are fine for me: The ParkAPI provides an attribute ‘original_uid’. When will we use ‘original_uid’ and when ‘original_id’? Thorsten Fröhlinghaus Dr. Technischer Leiter - Team Mobilitätsdaten & Innovationen T +49 711 23991-1138 @ ***@***.*** F +49 711 23991-23 NVBW - Nahverkehrsgesellschaft Baden-Württemberg mbH Wilhelmsplatz 11 70182 Stuttgart www.nvbw.de<http://www.nvbw.de/> [cid:NVBW_a90eddca-c536-413f-a211-e09ee1a4f760.jpg] Hinweise zur Datenverarbeitung nach der DSGVO erhalten Sie hier.<https://www.nvbw.de/datenschutz> Geschäftsführung: Volker M. Heepen, Monika Burkard ++ Aufsichtsratsvorsitzender Berthold Frieß ++ Amtsgericht Stuttgart HRB Nr. 17102 Von: Ernesto Ruge ***@***.***> Gesendet: Freitag, 24. Januar 2025 14:14 An: binary-butterfly/ocpdb ***@***.***> Cc: Fröhlinghaus, Thorsten ***@***.***>; Mention ***@***.***> Betreff: Re: [binary-butterfly/ocpdb] errors/questions for sw_stuttgart mapping doc (Issue #81) does the uid attribute in https://api.mobidata-bw.de/ocpdb/api/public/v1/locations<https://atpscan.global.hornetsecurity.com?d=oO-BKOWQdBu8zoW2a-KqQNg1yqI2Tm1GmHUYHE3zDBk&f=qef05houLaGY8Fnxj0ji_ahjozpZ1qoei0j5_rr-M30PuBufF_2vKgrTpcQ5bmYs&i=&k=wpHf&m=77jO13n8XJMKYtp8ZOL2-G8DVLx5bkhsSBHgghtWcSi5x_BggUWYzsRLoLBOILZa4aVhSuKrkYl117X00RTSQJShr3BLErX2X7DKOI-AoDDuuU10ODOcpe6XUw6L6887&n=14gLdHGeXxTQIsLw5ZraD-m0htFR0EOTX4soF7EMHDIIMRLEStPNEuc95G9sUQXR&r=mR0SFVtI9RaUE1vbeIGYRZl74lE0-00aKEqMk-osbXs1q7cUmsnng-H0PVC6hoWt&s=27e9910320c10679d0796be69733b3f832ff232bfd81a56fbd1ec2900199bb76&u=https%3A%2F%2Fapi.mobidata-bw.de%2Focpdb%2Fapi%2Fpublic%2Fv1%2Flocations> need to be unique? It's not allowed according to OCPI. If we keep within standards, we have to remove it. Instead, I would say that we backport the upcoming custom attribute functionality OCPI 2.3 and call it original_id, to make clear that this is the unique id from our data source. This also applies to source: this is not part of the OCPI standard. Holger suggested that it makes sense to support a strict URL parameter, to filter all non OCPI 2.2.1 compliant values. I like that idea, because it brings two worlds together: the need of additional fields which are required on a data gathering platform, and the ability to output strict OCPI. The id attribute in https://api.mobidata-bw.de/ocpdb/api/public/v1/locations<https://atpscan.global.hornetsecurity.com?d=9p_8fUyX_vS_vudsW0K6F4ZELqOVeEV211RDmAlrUFk&f=l2iUF33NbVkyMM6xrfMkxQfVHgg3YnHalbipBlW64hbIkpwTuT43dUS65TstCDL_&i=&k=kEAT&m=hgidFwaBKMsfSGjx5emKXw2bT9z-qwxamk0dbx-wb53QUWMH-nMNct5kBpl2NL-KfCwUOdUd7fLc5DBjDFPDwoF_zOJ73oqCGCTVH4FyJb4gryP5aWdY7H1N-WfkhvSO&n=KBw5Q1-j4GUawoGGnK1ge0KJ7oTMrVJ6PEggdrs45MEDEEP6-J37bWtIt6L9d_Vy&r=ehDE56EiuUuD9-eML1lXIUDqyPzBh4kaLdRKwyQsHY-DZJmHbY9xNT_QSFG4q8n5&s=6464dadb9bd4fc0cdae13cfe4dad9a721697822f4e2d1a4e966106072b30480f&u=https%3A%2F%2Fapi.mobidata-bw.de%2Focpdb%2Fapi%2Fpublic%2Fv1%2Flocations> is our own attribute, so we can generate a unique id, right? Yea, this is unique already (and has the wrong type, it has to be a string). — Reply to this email directly, view it on GitHub<#81 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A4X6PTKMO3LI5VWR5Z7XDJT2MI375AVCNFSM6AAAAABVZACALOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJSGUYDENZVGI>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[the-infinity]

OCPI is a bit inconsitent there: at locations and connectors, the unique identifier is called id, at evses, the unique identifier is called uid. To keep the logic, I think it would be best to use original_ as a prefix, so original_id at location and connector, and original_uid at evse. The rule behind it would be the prefix which always relates to the field name which exists in the standard.

[ThorstenFroehlinghaus]

Ok, I agree with this naming rule. Thorsten Fröhlinghaus Dr. Technischer Leiter - Team Mobilitätsdaten & Innovationen T +49 711 23991-1138 @ ***@***.*** F +49 711 23991-23 NVBW - Nahverkehrsgesellschaft Baden-Württemberg mbH Wilhelmsplatz 11 70182 Stuttgart www.nvbw.de<http://www.nvbw.de/> [cid:NVBW_a90eddca-c536-413f-a211-e09ee1a4f760.jpg] Hinweise zur Datenverarbeitung nach der DSGVO erhalten Sie hier.<https://www.nvbw.de/datenschutz> Geschäftsführung: Volker M. Heepen, Monika Burkard ++ Aufsichtsratsvorsitzender Berthold Frieß ++ Amtsgericht Stuttgart HRB Nr. 17102 Von: Ernesto Ruge ***@***.***> Gesendet: Freitag, 24. Januar 2025 16:03 An: binary-butterfly/ocpdb ***@***.***> Cc: Fröhlinghaus, Thorsten ***@***.***>; Mention ***@***.***> Betreff: Re: [binary-butterfly/ocpdb] errors/questions for sw_stuttgart mapping doc (Issue #81) OCPI is a bit inconsitent there: at locations and connectors, the unique identifier is called id, at evses, the unique identifier is called uid. To keep the logic, I think it would be best to use original_ as a prefix, so original_id at location and connector, and original_uid at evse. The rule behind it would be the prefix which always relates to the field name which exists in the standard. — Reply to this email directly, view it on GitHub<#81 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A4X6PTLEUHAESFKBEI7LK6T2MJI2JAVCNFSM6AAAAABVZACALOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJSG42DGNZXHE>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[the-infinity]

Addressed with version 1.3.0

[ThorstenFroehlinghaus]

Will you also update https://github.com/binary-butterfly/ocpdb/blob/main/docs/mapping/sw_stuttgart.md ?

[the-infinity]

Addressed here: #88