-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flattening addresses #51
Comments
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 ? |
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 :) |
@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} |
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 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 |
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.
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. |
Yes, I think it's fine to put the metadata into the extension. |
fixes #51 Flattened out because many countries have very different ways to describe an address, so better to leave it free. If one large string identifies a building then it's fine. The array is used when a Building, eg in LoD1.2, has several addresses. This is common in NL for instance, and we don't always have access to each BuildingUnit, so we just want to list all the addresses.
I think we should flatten addresses into a single string using local formatting conventions. Rationale:
The text was updated successfully, but these errors were encountered: