[Admins] Add Area type and allow only Point on Locality

[DavidKarlas]

With new relations we can now add multiple different geometries to one locality, here we are changing modeling for localities to always have point and in case it also has polygon adds it via new Area type which references Locality via localityId property.

Also included few minor changes into this PR:

• Removed mentioning disputed boundaries as missing feature. This was added few weeks ago, didn't realize it was mentioned here...
• Changed context property/relation name to contextId to reflect new guidance

[jenningsanderson]

View the changes to documentation and schema here: https://dfhx9f55j8eg5.cloudfront.net/pr/72

[jenningsanderson]

Looks good to me — would calling it administrativeArea instead of just area be more descriptive?

area is a bit of an overloaded term in geospatial, so I think it could be helpful to more clearly delineate that.

[ibnt1]

looks good, left couple minor comments, thanks!

[jwass]

Looks good to me — would calling it administrativeArea instead of just area be more descriptive?

area is a bit of an overloaded term in geospatial, so I think it could be helpful to more clearly delineate that.

I kind of agree but also it's within the admins theme so I feel like adding administrative is redundant. As I was reviewing I was thinking we might just want locality, boundary, and area or something like that. I agree that area is a bit of an odd duck here so maybe there's a better word (polygon?).

[jenningsanderson]

Looks good to me — would calling it administrativeArea instead of just area be more descriptive?
area is a bit of an overloaded term in geospatial, so I think it could be helpful to more clearly delineate that.

I kind of agree but also it's within the admins theme so I feel like adding administrative is redundant. As I was reviewing I was thinking we might just want locality, boundary, and area or something like that. I agree that area is a bit of an odd duck here so maybe there's a better word (polygon?).

Yeah — the only problem is that type is currently unique globally, not per-theme, so area or polygon would be forever associated only with this particular theme.

At least, that's how it's currently in the schema, but maybe it doesn't matter if type is reused b/n themes?

[jwass]

Yeah — the only problem is that type is currently unique globally, not per-theme, so area or polygon would be forever associated only with this particular theme.

At least, that's how it's currently in the schema, but maybe it doesn't matter if type is reused b/n themes?

Interesting. I actually didn't think type was unique globally?? I think the schema is usually seeing if both a theme and type match, then dispatching to the right type. Still have to check but if it is the case, would you think area is okay? Or still prefer administrativeArea?

[DavidKarlas]

I just want to add I"m super happy with current name of localityArea because it makes it super clear it adds areas to type before it which is locality...

[jwass]

I just want to add I"m super happy with current name of localityArea because it makes it super clear it adds areas to type before it which is locality...

Sounds good. I guess for consistency, should administrativeBoundary then be localityBoundary or something like that? Seems weird to have administrative only there but nowhere else.

[DavidKarlas]

FYI, I removed isMaritime property from localityArea because it needs more discussion... Since Landmass area type can be derived from data + I would like to use subType instead of property...

[DavidKarlas]

Got all needed approvals and resolved all open comments