Proposal: add "polygon" field into "location" table

[pavgra]

Not all locations are described by only latitude and longitude pair. E.g. county is an area, not a point, which is described by polygon. Therefore, it is proposed to add polygon field into location table to be able to store binary polygon data, which e.g. could take value from OpenStreetMap's planet_osm_polygon.way field.

Would be used by OHDSI/WebAPI#649

[gowthamrao]

@pavgra I think what you are bringing up is an interesting problem.

Persons belong to a location. Locations maybe precise pin-points or an approximate area e.g. some data sources may say provide an address that could be geocoded to lat/long; other data sources may provide a rough area e.g. person belongs to county A. Some relevant reading materials 1

So, I think what is being suggested is that if source data gives an area e.g. zip-3, zip-4, county, state etc, (i.e. in this case we cannot perform geocoding) are you suggesting we need to standardize it with a polygon from OSM?

[pavgra]

@gowthamrao, I would not stick explicitly to OSM, e.g. I am not sure whether GADM uses the same encoding for areas. So I would allow putting any binary representation of a polygon. But in general, yes, what I propose is to describe areas not just with lat-lon as pin-point but with something more appropriate.

[gowthamrao]

allow putting any binary representation of a polygon

so the suggestion is to in the OMOP CDM, 'a binary representation of a polygon', as part of the ETL process. What data/field type would this value be?

[pavgra]

@gowthamrao , I thought of blob

[cgreich]

Friends:

Wait. This is a little tricky. Because polygons are clearly no healthcare domains. They are not coming from the healthcare data. The domains we have are person, provider, care site, payer, cost and all the clinical event stuff.

I'd be happy for you to be thinking about this, and it is good stuff, don't get me wrong. But having everybody and their grandmother install a new table called POLYGON and having to explain what that is - not that keen.

[pavgra]

@cgreich , I haven't talked about a separate table. I have talked about adding a new field polygon into existing location table as alternative to existing latitude and longitude fields

[cgreich]

But one location can be in many Polygons: Newtown, Bucks County, Pennsylvania, USA, North America, Americas, Land mass. So, won't work.

[pavgra]

@cgreich , but you are talking about locations relationships which is a different topic. And that one doesn't contradict with a need to store bounds of each location anyway.

[pavgra]

Let me give an example of what I'm talking about:

location

Name	Lat	Lon	Polygon
255 Summit Trace Rd, Langhorne, PA, USA	40.217252	-74.924198	NULL
Langhorne, PA, USA	NULL	NULL	Binary data
PA, USA	NULL	NULL	Binary data
USA	NULL	NULL	Binary data

While 255 Summit Trace Rd is a point, Langhorne and upper - are areas. And yes, those are related to each other, but again - this is a different topic. Those relations can be built exactly like CONCEPT_ANCESTOR because they are derivable from lat-lon and polygons

[ablack3]

Closing this due to the length of time that has passed and the progress made in the GIS workgroup. Reopen if you like.