look into better way of doing latitude and longitude

[mortenoh]

I would suggest also adding projection system, and not just rely on WGS84

[edjez]

I'll strongly suggest we postpone this. Managing multiple projection systems seems to be closer to what many folks have to manage with GIS systems, not a facility registry. What country doesn't already manage their health facility locations as WGS84 or would be bothered by converting to it? If we don't come up with specific examples that are willing to share their needs with this group, we won't design this variability right and will try to do a generic 'catch-all' just in case.

On Jan 22, 2013, at 5:04 AM, Morten Olav Hansen notifications@github.com wrote:

I would suggest also adding projection system, and not just rely on WGS84

— Reply to this email directly or view it on GitHub.

[mberg]

Agree. I was just implying we explicitly say lat, long etc On Jan 23, 2013 5:25 AM, "edjez" notifications@github.com wrote:

I'll strongly suggest we postpone this. Managing multiple projection systems seems to be closer to what many folks have to manage with GIS systems, not a facility registry. What country doesn't already manage their health facility locations as WGS84 or would be bothered by converting to it? If we don't come up with specific examples that are willing to share their needs with this group, we won't design this variability right and will try to do a generic 'catch-all' just in case.

On Jan 22, 2013, at 5:04 AM, Morten Olav Hansen notifications@github.com wrote:

I would suggest also adding projection system, and not just rely on WGS84

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/facilityregistry/fred-api/issues/34#issuecomment-12574041.

[jason-p-pickering]

I think the issue is not about multiple projection systems, but rather a defined one. There are many countries which are not using WGS84. The ones I have had specific experience with are Rwanda, Ugunda, Solomon Islands, Thailand, Vanuatu and Tajikistan.In the case of Rwanda, there were three seperate UTM grids used. All of these countries manage their national geographical data in systems other than WGS84 for various reasons. It does not make a whole lot of sense to force them to use WGS84 simply because it may be simple. The facility registry should specify that a coordinate is required, but not force countries to use a particular one.

I think the need for multiple projection systems within a given registry is not so compelling, but it could be. The more important issue as I see it is simply to identify the coordinate system, which opens up a whole lot of other possibility to integrate with tools which will require this information.

[edjez]

Having the concrete example is helpful. Where in the Rwandan health system have you seen data users not ultimately converting to WGS84? (Both in MOH and CHAI all the info I saw was WGS84). I know they may be using different things in their GIS servers (but that's what they are for).

Are you suggesting having a selectable 'projection system' per dataset so it is known how it manages coordinates? UTM/MGRS/etc etc? it has other implications for data that needs to be stored and exposed. Seems to be responsibility of an external system, IMO, not a facility registry. In 3 years of running the underlying product -resource map - we haven't found one customer who needed UTM and they had trained field users, GIS import/export etc in most of the customers.

I'm all for it if it has demonstrated value and it's the priority bottleneck; until then I suggest we postpone (when it does become the bottleneck we'll still be here)

On Jan 23, 2013, at 2:20 AM, jason-p-pickering notifications@github.com wrote:

I think the issue is not about multiple projection systems, but rather a defined one. There are many countries which are not using WGS84. The ones I have had specific experience with are Rwanda, Ugunda, Solomon Islands, Thailand, Vanuatu and Tajikistan.In the case of Rwanda, there were three seperate UTM grids used. All of these countries manage their national geographical data in systems other than WGS84 for various reasons. It does not make a whole lot of sense to force them to use WGS84 simply because it may be simple. The facility registry should specify that a coordinate is required, but not force countries to use a particular one.

I think the need for multiple projection systems within a given registry is not so compelling, but it could be. The more important issue as I see it is simply to identify the coordinate system, which opens up a whole lot of other possibility to integrate with tools which will require this information.

— Reply to this email directly or view it on GitHub.

[jason-p-pickering]

I was there in September, and I imported a large bulk of data into the HMIS (no idea where it came from) with three separate UTM grids. Saw something similar in Uganda as well. Again, may depend on where you get the data. :)

What i am suggesting is that for a given facility registry, there be a single projection system. Not necessarily EPSG4326, but which ever they might choose. In the Solomons, the facilities were pegged to a MGRS, and there would be really no need to convert the data, when a lot of their other geographical data was already in the same coordinate system.

At the end of the day, it just seems to be to be an unreasonable restriction to place on an API of this type. We have no idea what will be other the other side of this API, but OGC already has all of this figured out. There just needs to be a mechanism to reflect the geographical data out in a standard format, and then it will be the clients problem for how to handle the data with a known and identifiable projection system. To state it another way, it would be like saying somehow in the spec that "All facility names must be in English". This is not always going to be the case.

No doubt that in the vase majority of cases, people CAN convert their data to lat/long, and there may be good reasons for doing so. But on the other hand, this should be a choice made by a given country. If the facility registry is deriving its data from a geographical database which is the primary source of information for easting/northings, this database could feasibly provide only easting/northing data and not long/lats? A bit of a devil's advocate point of view I know, but it would see that it would be simply little effort to define the easting/northings as true geographical coordinates as opposed to an assumed lat/long with no real projection information available to the client.

[bobjolliffe]

I am no expert on GIS systems, but it does seem to me that by requiring a facility registry to explicitly state the projection system it is using does not place a requirement on it to support all projection systems.

It is simply allowing for the fact that some other implementation can do so if that is what is required of it, what might be common in country etc. For a given implementation it seems that it doesn't necessarily create extra complexity.

Though I add again, I speak from a position of some ignorance here ..

On 23 January 2013 19:29, jason-p-pickering notifications@github.comwrote:

I was there in September, and I imported a large bulk of data into the HMIS (no idea where it came from) with three separate UTM grids. Saw something similar in Uganda as well. Again, may depend on where you get the data. :)

What i am suggesting is that for a given facility registry, there be a single projection system. Not necessarily EPSG4326, but which ever they might choose. In the Solomons, the facilities were pegged to a MGRS, and there would be really no need to convert the data, when a lot of their other geographical data was already in the same coordinate system.

At the end of the day, it just seems to be to be an unreasonable restriction to place on an API of this type. We have no idea what will be other the other side of this API, but OGC already has all of this figured out. There just needs to be a mechanism to reflect the geographical data out in a standard format, and then it will be the clients problem for how to handle the data with a known and identifiable projection system. To state it another way, it would be like saying somehow in the spec that "All facility names must be in English". This is not always going to be the case.

No doubt that in the vase majority of cases, people CAN convert their data to lat/long, and there may be good reasons for doing so. But on the other hand, this should be a choice made by a given country. If the facility registry is deriving its data from a geographical database which is the primary source of information for easting/northings, this database could feasibly provide only easting/northing data and not long/lats? A bit of a devil's advocate point of view I know, but it would see that it would be simply little effort to define the easting/northings as true geographical coordinates as opposed to an assumed lat/long with no real projection information available to the client.

— Reply to this email directly or view it on GitHubhttps://github.com/facilityregistry/fred-api/issues/34#issuecomment-12617464.

[mortenoh]

I don't think we should require that the registry should be able to convert between multiple systems, but a property for telling what projection system is used for the coords you are receiving might be useful. I'm fine with defaulting to WGS84 if its left blank.

[mberg]

Why not require the client to convert ahead of time. Storing things in the same projection seems the most sane to me. On Jan 24, 2013 8:12 PM, "Morten Olav Hansen" notifications@github.com wrote:

I don't think we should require that the registry should be able to convert between multiple systems, but a property for telling what projection system is used for the coords you are receiving might be useful. I'm fine with defaulting to WGS84 if its left blank.

— Reply to this email directly or view it on GitHubhttps://github.com/facilityregistry/fred-api/issues/34#issuecomment-12653887.

[mortenoh]

Yes, storing them in the same projection makes sense. But that projection might not be WGS84.

[jason-p-pickering]

This to me is sort of akin to allowing the client to submit their data in any language whatsoever, but without implicitly declaring it. In any given country, you may have potentially many languages, perhaps with many different scripts, think of Ethiopia for instance. Would we want a client to submit data to a registry without forcing them to declare what language they are submitting it in? Would we require a client to submit their data in Pig Latin (because that is what the API spec says) even though they use Amharic as their official language? And if so, would we want them to submit data to a registry without telling us what language it is that they have written the name of the facility in?

I guess I am missing why an API spec would get involved at all in requiring any given client to use any given language or projection system for that matter.You would think it would be a good think to allow clients to declare what language/projection system they are submitting their data in, and require that information to be submitting according to an ISO language code (in the case of language), a given encoding system (UTF-8), and perhaps a given projection system with a given EPSG code (in the case of the coordinates) Should the clients not do so, then of course assumptions are going to have to be made by other clients as to what the information in the registry actually is all about.

[edjez]

Suggest to have a group discussion - but recommend punting from 1.1

[mberg]

Update docs to be WSG84. Consider in future version ability to have support for other projections.