Huey Brantley wrote:
> Precision in coordinates allows one to enter them into their GPS and
> navigate to that point. If I'm looking for a cemetery, getting to the
> center of the county the cemetery is in is pretty pointless. Maybe
> its just my 20+ years in mapping/GIS that wants higher precision.
First of all, my intent here is not to tell anyone what precision of
coordinates to use. Rather, it is to present a tool which visualizes
the effects of (im)precision in a way that could help genealogists map
the fuzzy regions they work with. In essence, to bridge the gap between
genealogy, which deals in vague references and areas of uncertainty, and
GIS, which needs hard numbers.
I have nothing against necessary precision. But too much precision adds
nothing. And a careful LACK of precision can add value, as a way of
indicating general areas which would otherwise be hard to mark on a map,
since you don't really know where to put the marker. Naturally, this is
much more effective when the map displays the area of uncertainty, much
like a GPS receiver will often display a circle around your location
based on the accuracy of the fix. But even without that visual cue in
later use, my tool can help someone place a marker within their area of
interest without worrying about whether 42.379657 or 42.379664 is the
In your example, you certainly should not use county-level precision to
locate a cemetery. You need enough precision to get you to that
specific cemetery. But you don't need the coordinates of the bolt in
the SE corner of the flagpole base in order to find the whole cemetery.
To give a specific example...
The data from geonames.usgs.gov gives these coordinates for the Calvary
Cemetery in Hollister, CA: (36.8482879, -121.3777121)
That's 7 decimals of precision, which locates a point to within about
0.2 inches. Google Earth shows me that is the location of a pebble on
the east side of the east driveway about 340 feet in from the gate. If
you are looking for the cemetery, the location of that pebble means as
little to you as the location of that cemetery means to someone looking
for San Benito county.
Using my tool, I see that these coordinates are enough to uniquely
identify the cemetery, and get you right to it with your GPS:
All the extra digits serve no purpose for the task of locating the
cemetery. (You'd want 5 decimals to locate a headstone, though.)
Likewise, USGS gives this for San Benito county:
When this is all you really need for the county: (36.6, -121.1)
On the other hand, this tool is also useful for GAINING precision.
About 200 years ago, an ancestor lived on Maiden Lane, in New York City.
That's not enough to get actual coordinates with. In order to give him
a marker on the map, without something more specific, all I can do is
mark New York City, which is a BIG place. But by putting the box in my
tool around today's Maiden Lane, I see that I can reasonably approximate
his neighborhood as: (40.71, -74.01)
That marks about 1/4 square mile of lower Manhattan, which is a LOT more
precise than just sticking a marker on New York City. Doing the same
with his family lets me map their distribution around the neighborhoods
of New York, instead of just having a stack of markers in one spot for
> On Sun, Mar 2, 2008 at 8:45 PM, Dave Walton <dw-gramps@...> wrote:
>> Hm, I realize I left out a couple of points I meant to make...
>> - Place databases like geonames.org go down to the level of cities or
>> towns. Geocoding (computing coordinates based on address) is
>> notoriously inaccurate and often fails, especially on historical
>> addresses. GRAMPS users will often have information more precise than
>> city, but less precise than an actual building location. Perhaps just a
>> street name, or a particular block, or a distance from landmark, etc. A
>> tool like this is useful for determining approximate coordinates that
>> are better than just the city coords using that information.
>> - Besides adjusting zoom level based on precision of coordinates,
>> GeoView could also display the area of uncertainty, similar to the
>> bounding box I draw (though a circle, if possible, would be more
>> visually pleasing). That raises awareness that, like most Places, the
>> coordinates don't reference just a single, specific point, but rather a
>> general area of interest around that point, the size of which can vary
>> depending on the Place being referenced.
>> Dave Walton wrote:
>> > Howdy folks,
>> > This is semi-related to several different conversations that have taken
>> > place here recently. So I thought I'd share, in case anyone here is
>> > interested...
>> > For some time, I've been annoyed by the pointless over-precision of a
>> > lot of the coordinate data out there. I just doesn't make sense to give
>> > the coordinates of an entire country to within two inches. So I made
>> > this tool to help me find coordinates with more reasonable precision.
>> > (Thank you, Serge, for calling my attention to Mapstraction!)
>> > http://www.digger.net/projects/locator
>> > I can imagine several ways this might be useful to GRAMPS:
>> > - As a feature of GeoView, or perhaps a GeoView-enhanced place
>> > completion tool, it could help GRAMPS users find coordinates of places.
>> > - There was an idea recently about some sort of GRAMPS project places
>> > database. If that were to happen, something like this could be useful
>> > as part of the UI for building and maintaining that database.
>> > - Some of my code may (or may not) be useful in GeoView, such as
>> > picking a zoom level based on the level of precision of the coordinates.
>> > (I confess that I have no idea what GeoView can currently do. I am
>> > using Kubuntu, so I am missing a long list of dependencies to get
>> > gtkmozembed working.)
>> > Dave
>> > -------------------------------------------------------------------------
>> > This SF.net email is sponsored by: Microsoft
>> > Defy all challenges. Microsoft(R) Visual Studio 2008.
>> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> > _______________________________________________
>> > Gramps-devel mailing list
>> > Gramps-devel@...
>> > https://lists.sourceforge.net/lists/listinfo/gramps-devel
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> Gramps-devel mailing list