Not sure if you said where the lats and longs came from, but if any of your
geocodes are historical, or worked out from looking at paper maps rather
than a GPS then you should probably think about storing the Datum that was
used as the basis for the geocode. Different datums can vary by up to a few
hundred meters.
Peter
Peter Neish | Systems Officer, Victorian Parliamentary Library
Department of Parliamentary Services
Parliament of Victoria
From: Mark Jordan <[log in to unmask]>
To: [log in to unmask]
Date: 30/06/2012 01:53 AM
Subject: Re: [CODE4LIB] Storing lat / long
Sent by: Code for Libraries <[log in to unmask]>
Thanks everybody, looks like decimal degrees is the format to go with. Our
local GIS expert came to the same conclusion. Spatial db extensions are not
an option for us at the moment; we've got to store them as strings.
Mark
----- Original Message -----
> On Jun 28, 2012, at 3:46 PM, Matthew LeVan wrote:
>
> > I'd think it would depend on what you plan to do with the
> > coordinates once
> > you have them stored. If you intend to do anything at all
> > complicated
> > (spatial queries, KML generation, your own custom maps, area/volume
> > calculations), you might want to consider a spatial database
> > extension (
> > http://en.wikipedia.org/wiki/Spatial_database).
> >
> > I've used the SQLite SpatiaLite and Postgres PostGIS extensions,
> > and
> > they're fairly straightforward to setup.
>
>
> Agreed. If you're going to be searching on them (places w/in 50
> miles of (x), closest to (y)) ... spatial database extensions are
> the way to go.
>
> If you're just going to be returning them for display, it probably
> doesn't matter so much, but odds are someone in the future is going
> to ask about it.
>
> (and that being said; I store two copies of most anything coordinate
> or unit related ... one for searching that's well normalized, and
> one for display purposes ... database normalization be damned)
>
> -Joe
>
///////************************************************************///////////////
Parliament of Victoria .
Important Disclaimer Notice:
The information contained in this email including any attachments, may be
confidential and/or privileged. If you are not the intended recipient, please
notify the sender and delete it from your system. Any unauthorised
disclosure, copying or dissemination of all or part of this email, including
any attachments, is not permitted. This email, including any attachments, should
be dealt with in accordance with copyright and privacy legislation.
Except where otherwise stated, views expressed are those of the individual sender.
|
