Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Clarify meaning of multi-occurrence in Address.deliveryPoint #34

Open
desruisseaux opened this issue May 24, 2018 · 3 comments
Open

Clarify meaning of multi-occurrence in Address.deliveryPoint #34

desruisseaux opened this issue May 24, 2018 · 3 comments

Comments

@desruisseaux
Copy link
Contributor

CI_Address.deliveryPoint is a property of type CharacterSequence documented in ISO 19115 as: "the address line for the location (as described in ISO 11180, Annex A)". Since ISO 19115 allows many occurrences of that property, it has been interpreted in GeoAPI as if a CI_Address can have many delivery points. But the examples in data.gov file suggests that the multi-occurrence is rather for describing a single delivery point on many lines. Example (simplified):

<gmd:CI_Address>
   <gmd:deliveryPoint>
      <gco:CharacterString>151 Patton Avenue</gco:CharacterString>
   </gmd:deliveryPoint>
   <gmd:deliveryPoint>
      <gco:CharacterString>Veach-Baley Federal Building, Room 468</gco:CharacterString>
   </gmd:deliveryPoint>
   <gmd:city>
      <gco:CharacterString>Asheville</gco:CharacterString>
   </gmd:city>
   <gmd:country>
      <gco:CharacterString>USA</gco:CharacterString>
   </gmd:country>
</gmd:CI_Address>

If the later interpretation is correct (e.g. the multi-occurrence is for a single delivery points on many lines, not for multiple delivery points), then the following method signature:

Collection<String> getDeliveryPoints();

should be changed as below. Note the singular (because only one delivery point) and the use of List (because the order of those lines matter):

List<String> getDeliveryPoint();

In addition the documentation should clarify that interpretation.

@kinow
Copy link
Contributor

kinow commented May 25, 2018

+1

I think it's always going to refer to a single address, as also in

https://nzodn.nz/geonetwork/srv/eng/metadata.show?uuid=011b0eec-98ae-499a-9de6-70c9ef758170
and
https://data.linz.govt.nz/table/51997-landonline-parcel-ring/metadata/

Both examples above are used here at work. As well as 52N SOS, which has a method similar to what you suggest.

https://github.com/52North/SOS/blob/08ffd681f3b03569c7f1d227b0069b5399128cf0/hibernate/entities/src/main/java/org/n52/sos/ds/hibernate/entities/feature/gmd/AddressEntity.java#L54

But with a Set instead of a List. Do you know if there's anywhere in the original or revised ISO documentation that states a delivery point must not repeat in an address?

@desruisseaux
Copy link
Contributor Author

desruisseaux commented May 25, 2018

I found only the following in ISO 19115-1:2014:

deliveryPoint: address line for the location. Example: street number and name, suite number, etc.

with a maximum occurrence of N (thus allowing explicitly many instances, but without saying for which purpose).

If the intent is a single delivery point which may be one many lines, then maybe the property should be only an InternationalString (not a List or Collection) with lines separated by "\n" or "\r\n". This may encompass better the idea that it is a single entity (e.g. avoid the need to do a special case in user interfaces) and allow representation in different languages all at once. For example in Japan where the address may be written in Kanji or Romaji, I think that the choice of one alphabet or the other is done for the whole delivery point rather than a separated choice for each line.

@kinow
Copy link
Contributor

kinow commented May 25, 2018

So I think the Set is not necessary.

I am neutral to List/Collection versus "\n"/"\r\n". I think there are pros and cons in having the lines separated as different elements of a list, or wrapped as a single sentence separated by break lines.

Just looked up and noticed InternationalString is widely used in the project, with some implementations in Apache SIS. So I believe it should be fine going with that.

For example in Japan where the address may be written in Kanji or Romaji, I think that the choice of one alphabet or the other is done for the whole delivery point rather than a separated choice for each line.

I think so too. A few words may still appear in Romaji, like company names like FujiFilm, Jaxa, etc. But in the vast majority, I believe they will put everything with romaji, or everything with kanji/hiragana/etc.

desruisseaux added a commit that referenced this issue Jun 30, 2018
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants