search

freifunk / api.freifunk.net

Freifunk Community API
http://freifunk.net/api-generator/
49 stars 24 forks source link

Schema: location.address.Zipcode should be numberic #156

Closed christian-weiss closed 5 years ago

christian-weiss commented 5 years ago

All current community definitions (community API files) are setting numbers in this string field only. And this makes sense as the API files are for automated processing and the semantic of that field is pretty clear, even if JSON schema is a bit to "open" here.

Only exception is "Hagen": https://freifunk-hagen.net/hagen-api.json which sets "58135 Hagen" in this field.

As Freifunk expects one community per city, one file per city. It also expects that this community has its meeting place in exactly that city. That is the reason, why it has only location.address.Zipcode but no location.address.cityname, as there is already a city-field (location.city). It is optional to define a address for the meeting place, but when defined, then it should be a place in exactly the same city.

BTW: If this city is part of a meta community, with no meeting place in this city, then address field should be omitted. It is recommended to define an address for at least in the meta community API file, in that file / city where the meta community is located.

I asks the contact person of Hagen to change that field to just contain the postal code number via email, as i could not find a git repo to create a PR against it.

This ticket here is for improving the Freifunk JSON schema on next release.

On next schema version, we should change:

...
            "Zipcode": {
              "title": "ZIP",
              "type": "string",
              "description": "The zip code of your meeting place",
              "required": false
            }
...

to "numeric" with "min" and "max" set to 5.

PR will use this ticket.

christian-weiss commented 5 years ago

The adoption of Freifunk is very weak outside of germany, but we should still support other country - for that reason this field needs to stay a string-field. So in theory i could close this ticket now... Advanced checks can be done at consuming applications, for sure i will add such a check to: Freifunk Quality Assurance Report at http://community-registry.ff-hamm.de/

I will keep this ticket open for discussion, for a while, at least till i get feedback from Community Hagen.

andibraeu commented 5 years ago

yes, it's correct. ZIP code was modelled as String to be compatible with international formats

christian-weiss commented 5 years ago

Freifunk Hagen has uploaded a fixed community API file a couple of days ago. This feature (advanced checking of postal code) will be implemented as part of the Freifunk Community Registry Quality Assurance Report: https://github.com/christian-weiss/freifunk-community-registry-report/issues/1

For that reason i close this ticket here.

christian-weiss commented 5 years ago

Wels in austria has a wrong value (4600 Wels) in field location.address.Zipcode. Should be 4600.

http://leto.wels.funkfeuer.at:8080/meshviewer/data/FunkfeuerWels-api.json Team of Funkfeuer Wels was notified via e-mail.