Skip to content
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

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants