Flattening addresses

[kenohori]

I think we should flatten addresses into a single string using local formatting conventions. Rationale:

• Addresses are the only built-in nested attribute in CityJSON
• The address schema (from xAL) lacks fields that are needed to uniquely identify an address in many countries (e.g. toevoegsel in NL, building number/name, multiple levels of administrative subdivisions, etc.)
• The schema doesn't fit at all with how some countries format addresses (e.g. Japan and South Korea)
• A string with full address can be geocoded, but it's difficult if you don't know the right order to put the fields (which differ by country)
• Simpler is better!

[liberostelios]

I am not sure if flattening is a good option, necessary. But either way, maybe we should keep the standard fields and allow for extra ones.

Whatever we choose, maybe a good option would be to add a metadata item that describes what the address describes? Either the format of the flattened string or the extra fields of the address item. @Athelena ?

[Athelena]

I think this is a good point, addresses are indeed complicated so having guidance in the metadata can be super helpful. I only support this :)

[hugoledoux]

Some help: https://en.wikipedia.org/wiki/Address#Address_format

[hugoledoux]

I am not sure if flattening is a good option, necessary. But either way, maybe we should keep the standard fields and allow for extra ones.

@liberostelios But in CityJSON one can always add the properties she wants...

@kenohori Just a string for the description is fine IMO, but an address should then be {string + Point}

[balazsdukai]

I would like to revive this sleeping topic by adding that a single address per Building(Part) is not sufficient. So in any case the address member should be at least an array.

In the Dutch case we have several addresses/apartments within one building. A one-->one mapping would mean that we need to model each apartment as a separate, empty BuildingPart, since there is not interior geometry. I think that in this case, this approach would be redundant, unnecessarily complex.

The BAG data set has a one-->many mapping of Building-->addresses, which we could follow with cityjson.

Personally, I don't know much about how addresses are defined around the world, but by reading the discussion here about its diversity, my first reaction was to skip the xAL standard, since it suppose it'll fall short. Just as @kenohori describes it. Following the suggestion, I also support to allow arbitrary fields for the address definition. This would allow to store the addresses with the fields that are common or standard for a country, instead of trying to squeeze them into some international categories where they don't fit. I'm assuming that citymodels are first and foremost used within the country where they are created, thus using the local address definition is the most useful for the majority of the data users.

But since there are local fields, having metadata that describes what they mean is a good idea, as @liberostelios proposes.

I'm also in favor of keeping the address as an object, instead of stringifying it, because that makes it simpler to get the fields from them.

So putting all of the above together, which is more or less a summary of what has been discussed so far, I propose the following:

https://gist.github.com/balazsdukai/1400f2adb557bfdb81ebe1b046aff5dc

[hugoledoux]

The BAG data set has a one-->many mapping of Building-->addresses, which we could follow with cityjson.

I agree with this, for many cases attaching the address to the BuildingUnit is not feasible, and an array is the way to go. Let's make this v1.1 then.

Personally, I don't know much about how addresses are defined around the world, but by reading the discussion here about its diversity, my first reaction was to skip the xAL standard, since it suppose it'll fall short. Just as @kenohori describes it. Following the suggestion, I also support to allow arbitrary fields for the address definition. This would allow to store the addresses with the fields that are common or standard for a country, instead of trying to squeeze them into some international categories where they don't fit. I'm assuming that citymodels are first and foremost used within the country where they are created, thus using the local address definition is the most useful for the majority of the data users.

But since there are local fields, having metadata that describes what they mean is a good idea, as @liberostelios proposes.

I'm also in favor of keeping the address as an object, instead of stringifying it, because that makes it simpler to get the fields from them.

So putting all of the above together, which is more or less a summary of what has been discussed so far, I propose the following:

https://gist.github.com/balazsdukai/1400f2adb557bfdb81ebe1b046aff5dc

So the address is just a JSON object. This is easy to do.

The metadata is more complex, in your case it's just the translation of the fields. And that would be in the https://github.com/cityjson/metadata-extended or as an Extension.

[balazsdukai]

Yes, I think it's fine to put the metadata into the extension.