search

openreferral / specification

The Human Services Data Specification - a data exchange format developed by the Open Referral Initiative
https://openreferral.org
Other
117 stars 50 forks source link

geo-json & topo-json support #191

Open kinlane opened 6 years ago

kinlane commented 6 years ago

This was submitted via separate document from ISS, suggesting we....

HSDA only supports latitude and longitude but using geo-json (and topo-json) in addition would be more flexible by supporting more than just one point. Examples could be when shown on a map, the point of interest could now be shown along with topographic features like gradient, lines to indicate entrance (particularly if meandering) or parking more clearly.

Cskyleryoung commented 2 years ago

I would particularly be in favor of adding GeoJSON support to service_area, so that we explicitly expect and know where to store shape data.

MikeThacker1 commented 2 years ago

In the UK we use service_area to denote the area within which someone should live to be eligible for a service. We've extended service area to add:

Arguably you don't need both of these fields but it can help to make the extent available rather than have to look it up via a URI. And there may be reasons why a URI does not exist.

Cskyleryoung commented 2 years ago

I agree that extent is a necessary supplement to uri. In Hawaii, for example, the service areas for their 211 are quite intuitively organized according to custom shapes that don't match up with US Census data. There is no uri available for those.

On Tue, Feb 22, 2022 at 3:54 AM MikeThacker1 @.***> wrote:

In the UK we use service_area to denote the area within which someone should live to be eligible for a service. We've extended service area to add:

Arguably you don't need both of these fields but it can help to make the extent available rather than have to look it up via a URI. And there may be reasons why a URI does not exist.

— Reply to this email directly, view it on GitHub https://github.com/openreferral/specification/issues/191#issuecomment-1047616263, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYZRPLMBY4MW4BPEHCYU2DU4NMMLANCNFSM4EQKRFEQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

Cskyleryoung commented 2 years ago

It's a small thing, but can we use more descriptive key than extent? This is alwaysgeospatial shape data is it not?

On Tue, Feb 22, 2022 at 10:29 AM Skyler Young @.***> wrote:

I agree that extent is a necessary supplement to uri. In Hawaii, for example, the service areas for their 211 are quite intuitively organized according to custom shapes that don't match up with US Census data. There is no uri available for those.

On Tue, Feb 22, 2022 at 3:54 AM MikeThacker1 @.***> wrote:

In the UK we use service_area to denote the area within which someone should live to be eligible for a service. We've extended service area to add:

Arguably you don't need both of these fields but it can help to make the extent available rather than have to look it up via a URI. And there may be reasons why a URI does not exist.

— Reply to this email directly, view it on GitHub https://github.com/openreferral/specification/issues/191#issuecomment-1047616263, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYZRPLMBY4MW4BPEHCYU2DU4NMMLANCNFSM4EQKRFEQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

MikeThacker1 commented 2 years ago

@devinbalkind drew my attention to OpenStreetMap where you can define your own boundaries and theoretically you can define boundaries with URIs for anywhere in the world with Natural Neighbourhoods but YES I recognise some people just want to put the GeoJSON in the database.

I should point out that extent can be so big that we don't read it into a Google sheet via our Exporter.

We could rename extent to shape or geospatial_shape although that would introduce a minor backward incompatibility with UK implementations.

Cskyleryoung commented 2 years ago

It's not really worth messing up your systems, I think. I'll recant my suggestion to rename extent.

Yes, those darned GeoJSON files can get huge. A great deal of my team's work recently has been around compressing them into small but still usable shapes that we can filter by. It's been a big headache, but also kind of exciting work.

On Tue, Feb 22, 2022 at 11:49 AM MikeThacker1 @.***> wrote:

@devinbalkind https://github.com/devinbalkind drew my attention to OpenStreetMap https://peteris.rocks/blog/openstreetmap-administrative-boundaries-in-geojson/ where you can define your own boundaries and theoretically you can define boundaries with URIs for anywhere in the world with Natural Neighbourhoods https://neighbourhoods.esd.org.uk/ but YES I recognise some people just want to put the GeoJSON in the database.

I should point out that extent can be so big that we don't read it into a Google sheet via our Exporter https://exporter.openreferraluk.org/.

We could rename extent to shape or geospatial_shape although that would introduce a minor backward incompatibility with UK implementations.

— Reply to this email directly, view it on GitHub https://github.com/openreferral/specification/issues/191#issuecomment-1048057202, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYZRPIPLYIXKBTG27NW5HTU4PED5ANCNFSM4EQKRFEQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

Cskyleryoung commented 2 years ago

@MikeThacker1 @devinbalkind This issue took on a new dimension for me today. When using DBT to transform data into HSDS in BigQuery, BigQuery started nesting the entire service_area table inside some of my records, where I only wanted the value of the field service_area. The reason? The field at the table are named the same, and BigQuery was referencing the table by default. I haven't found a way to alias my way out of this pickle, so I just went ahead renamed my field to extent. No more issues.

I expect I'll encounter the same problem with language, where a table and the primary field share their name again. I think those are the only two instances of that in HSDS.

I also found it useful to add type to my service_area table with enums of "geojson", "topojson", and (for legacy systems or early state during transformation) "text".

MikeThacker1 commented 2 years ago

@Cskyleryoung I've added service_area.extent_type to my spreadsheet of proposals for the next version with an enum as you suggested plus KML.

Note that the UK version also has service_area.uri. Theoretically, a URI should resolve dependent on the content type requested although you need a way of knowing if the URI supports the content type you want.

If service_area.service_area is the only case of a table name matching a field name, it might be worth changing although it is strictly a backward incompatibility.

Cskyleryoung commented 2 years ago

Hi Mike,

Calling this out because it's such a perfect example:

...you need a way of knowing if the URI supports the content type you want.

That's exactly the type of use case I envisioned for at least one layer of profile: clarifying information about a particular instance of the schema that is retrievable via API.

...service_area.service_area is the only case of a table name matching a

field name...

There is one other instance that I found, and I'm having the same difficulties with it: language.language.

I could propose language.code' as a replacement (since it's recommended to be ISO639-* codes anyway), and possibly addinglanguage.description` for human readable labels as well, off the top of my head.

On Wed, Mar 16, 2022 at 8:38 AM MikeThacker1 @.***> wrote:

@Cskyleryoung https://github.com/Cskyleryoung I've added service_area.extent_type to my spreadsheet of proposals for the next version with an enum as you suggested plus KML.

Note that the UK version also has service_area.uri. Theoretically, a URI should resolve dependent on the content type requested although you need a way of knowing if the URI supports the content type you want.

If service_area.service_area is the only case of a table name matching a field name, it might be worth changing although it is strictly a backward incompatibility.

— Reply to this email directly, view it on GitHub https://github.com/openreferral/specification/issues/191#issuecomment-1069269445, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYZRPMT46ZDVCDPOVZQMZDVAH6AXANCNFSM4EQKRFEQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>