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

Geometry input format #9

Closed
duncandewhurst opened this issue Aug 21, 2023 · 4 comments
Closed

Geometry input format #9

duncandewhurst opened this issue Aug 21, 2023 · 4 comments

Comments

@duncandewhurst
Copy link
Collaborator

I'm creating this issue to follow up on the question in GFDRR/rdl-standard#197 about how to enter coordinates in the spreadsheet template.

The RDLS Location sub-schema is based on a GeoJSON object. In particular, it has the following fields in common (in order of complexity):

  • centroid: The coordinates of the centre of the geographical area.

This field is an array of numbers. It must contain exactly two numbers with longitude (easting) first and latitude (northing) second.

Since those rules apply to both JSON and spreadsheet format, I suggest that we update the field description as follows:

The coordinates of the centre of the geographical area, represented as exactly two numbers with longitude first and latitude second.

In spreadsheet format, the correct way to enter it is as a semicolon-separated list, e.g. 0;0. That is already covered by the input guidance in the spreadsheet template.

  • bbox: A geographic bounding box delimiting the geographical area.

This field is an array of numbers. It must contain exactly four numbers with the first two numbers being the longitude and latitude of the most southwesterly point and the second two numbers being the longitude and latitude of the most northeasterly point.

As with centroid, those rules apply to both JSON and spreadsheet format, so I suggest that we update the field description as follows:

A geographic bounding box delimiting the geographical area, represented as exactly four numbers with the first two numbers being the longitude and latitude of the most southwesterly point and the second two numbers being the longitude and latitude of the most northeasterly point.

In spreadsheet format, the correct way to enter the bounding box is as a semicolon-separated list, e.g. 0;0;10;10. That is already covered by the input guidance in the spreadsheet template.

  • geometry (A Geometry object with two properties):
    • .type: The GeoJSON geometry type that is described by .coordinates, from the closed geometry_type codelist.
    • .coordinates: One or more GeoJSON positions according to the GeoJSON geometry type defined in .type.

This one is a bit more complicated since the type and length of coordinates depends on the geometry type. Flatten Tool's standard semicolon- and comma-separated list format only supports two levels of nested arrays so it is only possible to enter Point, MultiPoint and LineString geometries in spreadsheet format. The correct way of doing that is to use semicolons to separate the first level of array items and commas to separate the second level, e.g. 0;0 (Point) 0;0,1;1 (MultiPoint), 0;0,1;1,2;2 (LineString). However, that is quite complicated for users and, in any case, I expect that the most common geometry type is going to be Polygon which cannot be represented in this format.

Happily, we recently implemented support for the well-known text representation of geometry in Flatten Tool. I suggest that we enable WKT in the template, which will replace the geometry.type and geometry.coordinates fields with a single geometry field into which users can enter the WKT representation of the geometry, e.g.

image

This change doesn't require any updates to the schema since Flatten Tool handles the conversion from WKT to GeoJSON for validation. We can then add the following input guidance to the spreadsheet for the geometry field:

Enter a well-known text value, e.g. POLYGON ((30 10, 40 40, 20 40, 10 20, 30 10))

I think that is preferable since it is the only way that Polygon geometries can be represented in spreadsheet format and since the WKT format should be familiar to GIS analysts and copy-pastable from GIS tools.

@matamadio let me know if this sounds good and we can make the changes suggested above.

@matamadio
Copy link
Collaborator

See proposed solution for #197: bbox as only option.

@duncandewhurst
Copy link
Collaborator Author

@matamadio since the outcome of GFDRR/rdl-standard#197 was to keep geometry, are you happy with using WKT for geometry in the spreadsheet format?

Per the issue description, it's simply a case of setting an option in Flatten Tool and adding the following input guidance to the spreadsheet for the geometry field:

Enter a well-known text value, e.g. POLYGON ((30 10, 40 40, 20 40, 10 20, 30 10))

@matamadio
Copy link
Collaborator

Yes, WKT is good and easy.

@duncandewhurst
Copy link
Collaborator Author

Great. I've done that.

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