[Talk-us] USGS Large-Scale Imagery degraded this month :(
tchaddad at gmail.com
Sun Dec 18 22:34:38 UTC 2016
On Sun, Dec 18, 2016 at 11:59 AM, Ian Dees <ian.dees at gmail.com> wrote:
> I run the tile.openstreetmap.us server and noticed this change. Thanks
> for finding the USGS link: I saw it a while ago but then couldn't find it
> when I was trying to debug the problems with the server. The
> "usgs_large_scale" layer on tile.openstreetmap.us is now caching the
> USGSNAIPPlus layer, but the URL they provide both has worse imagery and is
> run from a much slower server (so my caching operation takes quite a bit
> longer and results in occasional 404s to the end user).
> I will try to contact a couple of the folks I know at USGS (maybe they're
> still on this list and could respond?), but it might be the case that we
> need to request the imagery and build the desired layer ourselves...
> On Sun, Dec 18, 2016 at 2:43 PM, David Kewley <david.t.kewley at gmail.com>
>> For a lot of my satellite imagery tracing, I've found it very useful to
>> go back and forth between Bing and USGS Large-Scale Imagery, which provides
>> at least 1-m resolution across the U.S., and in some areas (e.g. urban
>> areas) provides nice 1-foot resolution orthoimagery that aligns very well
>> in my local area with Bing imagery.
>> Well, I should say "provided", past tense. For the past couple of weeks
>> or so, I've noticed that the the USGS LSI has seemed to degrade in many of
>> my local imagery tiles, and I've finally looked into why that might be so.
>> For example, at this location, today (current state of imagery tile
>> caching, perhaps mostly local to me?)
>> when using USGS LSI, I see the NE, NW, and SW imagery tiles look fine,
>> but the SE tile is much lower quality, clearly from a different set of
>> imagery. I could swear this area was formerly seamless with the good
>> It looks like this month's degradation is probably a downstream effect of
>> this change:
>> Before USGS made this change, I saw identical imagery if I used iD's
>> built-in USGS LSI, versus using the following setting in Custom imagery in
>> The OSM built-in USGS LSI was faster than this custom link, I believe
>> because the custom link is dynamic (not cached by whoots), and it takes two
>> round trips, a lookup by iD to whoots, then by whoots to USGS, and probably
>> a dynamic conversion by whoots. I'm not an expert in this, so could easily
>> have some of this wrong.
>> USGS LSI seemed faster -- perhaps it was static on the backend, or cached
>> better or something. The OSM built-in USGS LSI imagery appears to be served
>> by openstreetmap.us, though I know none of the details of how it's
>> Anyway now per the above announcement link, the *USGS_EROS_Ortho* URL is
>> deprecated, and is no longer served, and it seems like the following whoots
>> dynamic lookup imagery is the appropriate one, based on the
>> USGS-recommended replacement for the deprecated imagery:
>> Indeed when I use this in the Custom imagery setting in iD, I see the
>> same degraded imagery that the built-in USGS LSI setting now gives me.
>> Can anyone shed further light or corrections on any of this? Any idea
>> whether it's technically possible and legally permissible to have
>> openstreetmap.us serve the older, better USGS LSI instead of the newer,
>> worse stuff? If so, upon further discussion I'd probably support such a
>> move, and possibly even offer to help with the conversion. :)
>> Talk-us mailing list
>> Talk-us at openstreetmap.org
> Talk-us mailing list
> Talk-us at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Talk-us