Modification to GEO Code Field

[RossEvans]

No one seems to disagree that the right place to store such data is within MLS, once there is functionality there to support it.. And it seems that some kind of solution there is on the roadmap but won't be released soon.

The analytical question then arises about where best to store coordinates as a temporary fallback. All the above comments reinforce my own opinion that the best way to do that is in external datbabase tables, with a process in place to keep them sync'd with the master MLS records. That is just part of the logic of maintaining the geododed addresses and their derivative coordinates.

[russellhltn]

For completeness, I'll toss out another idea: Compressing the lat/lon to fit into the 8 character geocode. If you live in a physically small ward you may only need the last 4 digits of each number. You'd have to add the missing significant digits when exporting, but that's less hassle then having an external database that has to be synced.

Or do we even need the last digit? All the digits is about a 6' square. Is a 60' square "close enough"?

If we remember that lossless compression is simply a more efficient way to express an idea, many other thoughts come to mind. Perhaps expressing it in Hex. Or higher. I work with one application that's designed to store files for a enterprise. It names files and folders in base 42. While that would work, that's not exactly human friendly.

[RossEvans]

For completeness, I'll toss out another idea: Compressing the lat/lon to fit into the 8 character geocode..

I hesitate to bring this up, because I certainly do not advocate this solution in this context. But FYI there is a proposed standard, the Natureal Area Coding System, to store coordinates in 10- or 8-character strings. I don't think the world is beating a path to their door.

In any event, I still prefer decimal lat/lon. Personally, since I fail to see many advantages in manually entering these coordinates into MLS without supporting geocoding functionality, I would prefer not to do this even if the legacy "GEO Code" field were big enough to accommodate the data. This field really was conceived to contain codes that represent aggregated areas, not point coordinates.

[aebrown]

In any event, I still prefer decimal lat/lon. Personally, since I fail to see many advantages in manually entering these coordinates into MLS without supporting geocoding functionality, I would prefer not to do this even if the legacy "GEO Code" field were big enough to accommodate the data. This field really was conceived to contain codes that represent aggregated areas, not point coordinates.

I would also add that the GEO Code field is used for a very important, albeit relatively rare (except in some places in Arizona) purpose -- boundary changes. The capability in stake MLS for analyzing boundary proposals depends on the stake GEO Code field. Thus I would strongly advise against using that field for any other purpose. When boundary changes occur, the process is generally kept very confidential among just a few people, and misusing the GEO Code fields may complicate this process.

[jbh001]

I hesitate to bring this up, because I certainly do not advocate this solution in this context. But FYI there is a proposed standard, the Natureal Area Coding System, to store coordinates in 10- or 8-character strings. I don't think the world is beating a path to their door.

And making such a culturally naive statement such as

"...the most popular characters widely used in natural languages such as English, French, Spanish, German, Chinese, ..."

instead of "the most popular characters from the Roman alphabet" doesn't help their cause.
Only Romanized Chinese uses these characters. "Popular" Chinese (if there is such a thing) uses logograms called sinographs.

This also implies that Arabic, Hebrew, Cyrillic, Greek, and Hanzi writing systems are from un-"natural languages" even though Arabic numerals have replaced most other number systems throughout world. (Think of that, English uses a Roman script and Arabic numerals instead of an Arabic script and Roman numerals.):eek:

Additionally, While their coding system works fine for terrestrial coordinates, since they want to extend it to deep space as well, at what distance from the earth's core does one stop figuring in the rotation of the Earth? Otherwise the coordinates for all objects in space would be constantly in flux unless the earth stopped rotating and orbiting the sun. (At least it was not very well explained in their article how this transition should be made.)

And more to the point, what NAC would I use to code my Home Teaching route on the future lunar base station? :p:D

No wonder the "world" isn't beating a path to their door.


But I digress.

[jbh001]

All the above comments reinforce my own opinion that the best way to do that is in external datbabase tables, with a process in place to keep them sync'd with the master MLS records

You left out my iPhone integration part.