-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments
See proposed solution for #197: bbox as only option. |
@matamadio since the outcome of GFDRR/rdl-standard#197 was to keep 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
|
Yes, WKT is good and easy. |
Great. I've done that. |
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:
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: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
(AGeometry
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
andgeometry.coordinates
fields with a singlegeometry
field into which users can enter the WKT representation of the geometry, e.g.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: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.
The text was updated successfully, but these errors were encountered: