[aprssig] Re: FindU Maps Quirky

Ray McKnight shortsheep at worldnet.att.net
Mon Feb 7 15:34:39 EST 2005


Gerry, what would be involved in setting up an SDTS server?
How large is the database?  How much processing power would be 
recommended?  Is the data publically available like Tiger?
Once one has the data, what would be the recommended plan to
convert it into useable files of a size that could be put
online?  Would ArcView be the best tool to use for the conversion?
Or if not "best", at least acceptable to the task, as that's all
I've got right now.  And I guess I should also ask if SDTS data
were converted and provided to ARPSWorld, would the resultant
files be more of a load than the current data?  That is would
Existing servers be able to handle it or would we also need to
upgrade the servers to handle the task?  Would bandwidth increase,
And if so by what factor?  Would you be able to provide a small
sample of a converted SDTS data set to compare to existing FindU
maps?

-----Original Message-----
From: aprssig-bounces at lists.tapr.org [mailto:aprssig-bounces at lists.tapr.org]
On Behalf Of Gerry Creager N5JXS
Sent: Monday, February 07, 2005 05:21
To: TAPR APRS Mailing List
Subject: Re: [aprssig] Re: FindU Maps Quirky

Time's short, but I feel obligated to answer this.

The origin of a LOT of the maps we're using is the Census Bureau's 
TigerMap line files.  A lot of their data are derived from the USGS SDTS 
linefiles.

Recently I went through the xercise of determining the accuracy of 
TigerMap data with someone in the New York area.  Despite what I've been 
told over the years, regarding accuracy of the USGS maps... and what 
I've found of their accuracy... we eventually determined that Census 
munges these files with their own "data" to reflect what THEY need. 
What CENSUS needs includes tract data that may not be consistent with 
MAP data.  If one of their folks goes out and drives an area, 
hand-sketching a tract, and reflects in that drawing changes to roads, 
you may very well see changes to a TigerMap changed based on a sketch 
and NOT a more consistent method of mapping.

NIMA (now NGA) and USGS mean it when they claim to comply with National 
Map Accuracy Standards.  Apparently, Census does not, and since they're 
NOT a mapping agency, no one has called 'em on it.

Why should publc funds pay for TigerMaps?  Simple:  They're doing what 
Census needs, and that's what Census had 'em created for.

To put a point on it, Tiger is more a picture than a map.  The metadata 
associated with the Census info are "OK" probably, as that's what 
they're interested in, but for MAP use like we're doing, we've been 
going to the wrong well.

TigerMaps have been a convenient way to get what we thought were 
reliable maps for years.  We just did not do our due diligence.  It's 
OUR fault for using these maps imroperly, not theirs.  If you actually 
read their website, which I'd glossed over so long, you find the 
appropriate disclaimers.

What I guess I'm saying is, as USGS flies and updates (electronically) 
all their SDTS mapping resources, that's a good way to go.  If someone 
wanted to snag the SDTS data and turn 'em into shapefiles, and serve 
these out as shapes, and even rasters, that's a service to THIS 
community that'd be a good thing.  It's a service to a larger community 
that'd be appreciated, too.  USGS doesn't have the mission or resources 
to serve these data out like that, and if y'all are following the new 
budget the Prez is about to submit to Congress, I don't see Commerce 
(NOAA and USGS) getting more money in the next, oh, decade...

gerry

Ray McKnight wrote:
> Okay, so public funding provides the incentive to create these databases?
> If the results are so poor as to be basically unusable, then why should
> Public funds (we're talking specifically within the USA here) be 
> continued?  There are many other programs that are publicly funded, AND
> Result in enforcement by various government agencies if the user fails
> To comply - I'm referring to NIMA charts and commercial shipping, the
> Charts need (**MUST**) be accurate and the ships must navigate accurately
> According to those charts, if the ship doesn't there's heavy penalty
> For failing to navigate properly.  But if the charts are wrong, then the
> Ship can easily claim false navigational info was provided to them and
> Say they only followed what was required of them to use.
> 
> APRS certainly isn't such a high profile user of public data,
> Who cares if your house is shown 1 mile off an APRS map, or your car
> Is in the wrong lane of an interstate.  But if public funds provide the 
> Means for the data to be collected and provided to us, and it's
> Not sufficiently accurate as to be useful, then why continue to
> Fund its programs??
> 
> Make them accountable!!!!  ONE MILE+ ERROR IS REDICULOUS!!!
> 
> 
> 
> -----Original Message-----
> From: aprssig-bounces at lists.tapr.org
[mailto:aprssig-bounces at lists.tapr.org]
> On Behalf Of Stephen H. Smith
> Sent: Monday, February 07, 2005 00:53
> To: TAPR APRS Mailing List
> Subject: [aprssig] Re: FindU Maps Quirky
> 
> 
> 
> Ray McKnight wrote on 2/6/2005, 11:21 PM:
> 
>  > Steve, if you zoom in to street level on my FindU map,
>  >
>  > You'll notice that although I am actually located about 1 mile
>  >
>  > From the water, a significant amount of the streets in my neighborhood
>  >
>  > Are depicted as being in Puget Sound, yeah, in the water!
>  >
>  >
>  >
>  > Gee, looking at Seattle a little closer now, there seems to be
>  > thousands of streets
>  >
>  > Depicted as being in the drink.  Any hope of correcting this??
>  >
>  > Does this link show what I'm talking about:
> 
> This has nothing to do with findu!
> 
> Street information, outlines of cities, counties, states, and of bodies 
> of water are typically stored in separate databases and then drawn as 
> multiple layers on top of each other.   The map you see is assembled 
> on-the-fly from multple databases at aprsworld.com at findu's request. 
> In turn,  the various layers of data come from different public-domain 
> sources and have varying degrees of accuracy, especially when data 
> referenced to one datum is converted to another.
> 
> The water features database which contains coastlines, lakes and rivers 
> seems to have major errors in it.  I see the same problems here in 
> Southern California where most of Santa Monica, LAX and parts of the San 
> Diego Freeway (I-405) are "underwater".  [And, please, no smart cracks 
> about them really being that way after the recent January floods!]
> 
> 
> The real issue is how much do you want to <<PAY>> to have access to 
> commercially enhanced and corrected data versus using free public domain 
>   data???
> 
> 
> Note:  You can see some similar errors in Precision Mapping 7.0   Zoom 
> in on the channel between the eastern tip of Michigan's Upper Peninsula 
>   and Sault Ste Marie, Ontario.   You will see Canadian roads, including 
> Ontario Route 548 apparently in the water, along with a bunch of small 
> towns.  Somehow the outline of an entire island (St Joseph's) slipped 
> through the cracks of the Canadian database provided to Undertow 
> software by GDT (Geographic Data Technology).
> 
> 
> 
> 
> Stephen H. Smith                wa8lmf (at) aol.com
> 
> Home Page:                      http://wa8lmf.com
> 
> New/Updated Symbols for         http://members.aol.com/wa8lmf/ham
> UI-View and APRSplus:
> 
> 
> 
> 
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 

-- 
Gerry Creager -- gerry.creager at tamu.edu
Texas Mesonet -- AATLT, Texas A&M University	
Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.847.8578
Page: 979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig





More information about the aprssig mailing list