Re: [Talk-us] rasters of climate change

[TC Haddad]

The NASA Earth Observatory has a page on the retreat of the Columbia
Glacier in Alaska:

https://earthobservatory.nasa.gov/Features/WorldOfChange/columbia_glacier.php

All the false color NASA images in the series are downloadable [1], Or you
can go to the USGS options for Landsat download [2] if you want source
images.

You can also view a true color 36-year time lapse on Google Earth Engine
here:

https://earthengine.google.com/timelapse/#v=61.05155,-147.08207,8.644,latLng=2.33

good luck!

[1]
https://earthobservatory.nasa.gov/Features/WorldOfChange/columbia_glacier.php?all=y
[2] https://landsat.usgs.gov/landsat-data-access


On Sat, Apr 15, 2017 at 3:12 PM, Clifford Snow 
wrote:

> Not sure if talk-us is the best place to ask. We don't use raster data for
> much more than background tracing. The only suggestion I have is to look at
> Landviewer [1] for areas you know that have been reported as having climate
> changes impacts and compare years. Landsat will go back a number of years.
> If you want to get more sophisticated, use QGIS to compare vegetation from
> then to now using the semi-automatic classification plugin.
>
> Or just visit any lake in Northern Minnesota and ask the locals.  I've
> spent many summers on Gull Lake.
>
> [1] https://lv.eosda.com
>
> Best,
> Clifford
>
>
> On Sat, Apr 15, 2017 at 5:45 AM, moira walsh 
> wrote:
>
>>
>> I'm looking for before and after rasters documenting climate
>> change-anywhere.
>> If anyone can point me in the right direction, I'd really appreciate it.
>> Thank you!
>>
>> --
>>
>>
>>
>>
>>
>>
>> Moira Walsh MPH
>> www.waterinanutshell.net
>> 507 210 6420 <(507)%20210-6420>   Texts are O.K.
>>
>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>
>
> --
> @osm_seattle
> osm_seattle.snowandsnow.us
> OpenStreetMap: Maps with a human touch
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] USGS Large-Scale Imagery degraded this month :(

[TC Haddad]

http://www.directionsmag.com/pressreleases/usgs-cutting-high-resolution-ortho-imagery-program/479365



On Sun, Dec 18, 2016 at 11:59 AM, Ian Dees  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 
> wrote:
>
>> 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?)
>>
>> https://www.openstreetmap.org/edit?changeset=44464607#map=19
>> /33.56194/-117.67451
>>
>> 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
>> imagery.
>>
>> It looks like this month's degradation is probably a downstream effect of
>> this change:
>>
>> https://www.usgs.gov/news/usgs-national-map-orthoimagery-
>> map-services-transition-and-other-map-service-changes
>>
>> 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
>> iD:
>>
>> http://whoots.mapwarper.net/tms/{z}/{x}/{y}/0/http://raster.
>> nationalmap.gov/arcgis/services/Orthoimagery/USGS_EROS_Ortho
>> /ImageServer/WMSServer?
>>
>> 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
>> served.
>>
>> 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:
>>
>> http://whoots.mapwarper.net/tms/{z}/{x}/{y}/1/https://servic
>> es.nationalmap.gov/arcgis/services/USGSNAIPPlus/MapServer/WMSServer?
>>
>> 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. :)
>>
>> Thanks!
>> David
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] NAIP US Aerial Imagery

[TC Haddad]

  Does this mean that NAIP will be removing WMS from future services
 and will only support JSON and SOAP?   (which I cannot get JOSM to
accept).

Just to comment on this one point: As a federal agency, the USDA is
*required* to support the open standard option of the WMS service type, so
it *should* be available.

In looking at all the different state NAIP imagery sets listed in their
directory here: http://gis.apfo.usda.gov/arcgis/rest/services/NAIP, every
single other state lists the WMS option, so it's clearly an error that
South Carolina is missing it.

Hopefully the service maintainers will catch on and correct soon, but if
you or others have a contact it is worth an email to make them aware, both
of the mistake, and of the customer base for the open standard option.



On Wed, Aug 12, 2015 at 2:26 PM, Mike N nice...@att.net wrote:

 On 8/12/2015 5:15 PM, Jonah Adkins wrote:

 you can use the SC Image Service as a custom background in iD or JOSM
 using this link

 *
 http://arcgis-level-fixer.elasticbeanstalk.com/http://gis.apfo.usda.gov/arcgis/rest/services/NAIP/South_Carolina_2015_1m/ImageServer/arcgis/z/{z}/y/{y}/x/{x}
 
 http://arcgis-level-fixer.elasticbeanstalk.com/http://gis.apfo.usda.gov/arcgis/rest/services/NAIP/South_Carolina_2015_1m/ImageServer/arcgis/z/%7Bz%7D/y/%7By%7D/x/%7Bx%7D
 *



 That worked for me as a TMS service in JOSM.   Thanks!



 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-us

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Facts about the world

[TC Haddad]

On Sat, Apr 4, 2015 at 2:21 PM, Darrell Fuhriman darr...@garnix.org wrote:

TIGER is much older than reasonably portable GPS units.


According to [1] pre-TIGER paper map sources were below the quality of the
1:100,000 DLG data outside of urban areas. Many of the crazy spaghetti data
areas we see probably haven't changed geometry in TIGER much since since
the mid-1980's when they were digitized the first time. They were never
intended for mapping, but rather were attribute rich for relative
geocoding. We shouldn't be surprised they as bad as they are. Many of the
processes for rural counties to contribute modern geometry (not attributes)
to TIGER only gained steam after the date that OSM sucked it it's first big
import, so the bad areas never benefitted from the geometry improvements.
It is what it is...

All this is to say is that it's important to understand the origins of any
data - many of the complaints people have about government data sources are
easily explained if you trace the origins. For example many people don't
know that the original source of the digital spatial coordinates of
uncorrected GNIS point data was the centroid of the cartographic labels on
24k topo quads. This entirely explains why the points are most often next
to, rather on top of the feature being labeled. Yet complaints abound
because for OSM scales, the data is imperfect. So it goes.

[1] http://geospatial-solutions.com/tiger-database-historical-perspective/
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Misspelled names

[TC Haddad]

name=Walmart Neighborhood Market is a real thing, and probably shouldn't
be corrected.

They have different branding than a regular Walmart (green and yellow vs.
the regular Walmart blue and yellow).

Here's the one on hwy 99 in Milwaukee OR:

https://www.google.com/maps/@45.4098553,-122.627165,3a,75y,14.1h,92.52t/data=!3m4!1e1!3m2!1sDBmlbyc_1EdyH4tg4vGNDg!2e0


On Wed, Dec 17, 2014 at 6:20 PM, Peter Dobratz pe...@dobratz.us wrote:



 On Wed, Dec 17, 2014 at 2:13 PM, Mike Henson mikehen...@hotmail.com
 wrote:

 I am also having an issue with Walmart, should it be a Marketplace,
 Supermarket, Department store??? All 3 are used in OSM in Oklahoma.


 Generally, Walmart is tagged as shop=department_store.

 However, there are a few location in the Portland, Oregon area that are
 zoned to only allow grocery type stores.  These are tagged:

 name=Walmart Neighborhood Market
 shop=supermarket

 Peter



 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] NHD import

[TC Haddad]

If it were coastal Oregon or SW Washington, there would be a good chance
that those were Cranberry farms (bogs).

Tanya

On Mon, Apr 9, 2012 at 6:28 AM, Brett Lord-Casitllo marigol...@yahoo.comwrote:

Most recent USGS topos show that area as water features.
 NAIP 2012 shows water there; looks like wetlands restoration maybe?
 --Brett
 Brett Lord-Castillo
 Information Systems Designer/GIS Programmer
 St. Louis County Police
 Office of Emergency Management
 14847 Ladue Bluffs Crossing Drive
 Chesterfield, MO 63017
 Office: 314-628-5400Fax: 314-628-5508
 Direct: 314-628-5407


 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[TC Haddad]

On Fri, Feb 17, 2012 at 12:01 PM, Paul Johnson ba...@ursamundi.org wrote:

 but overall, the automation saved countless hours of manual name expansion
 for the minor cost of having to deal with a very small number of largely
 regionally-isolated edge cases.


Can someone explain the original point of name expansion? Is it so that
devices that give audio directions using text-to-speech can read fluently?
Or was it really all about saving time?

Because there are other use cases where expanded names are not desirable,
particularly in cartography. When map or screen real estate is minimal,
expanded names can be downright detrimental to utility.

For example: in Portland all the expanded quadrant names (NE,NW, SE, SW)
really detract from the experience of using osm extracts on handheld GPS.
All the streets in an area of interest end up looking like they have the
same name because all that fits on the street segments is the first word of
the expanded quadrant label and not the real part of the name. So NE
Tillamook and NE Hancock both just label as Northeast... and that is
separate from the issue that people don't actually write addresses here as
Northeast Tillamook.

Anyway, maybe that is an edge case example, but I guess it bugs me.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)

[TC Haddad]

On Fri, Feb 17, 2012 at 2:42 PM, Paul Johnson ba...@ursamundi.org wrote:

 On Fri, Feb 17, 2012 at 1:41 PM, TC Haddad tchad...@gmail.com wrote:

 On Fri, Feb 17, 2012 at 12:01 PM, Paul Johnson ba...@ursamundi.orgwrote:

  but overall, the automation saved countless hours of manual name
 expansion for the minor cost of having to deal with a very small number of
 largely regionally-isolated edge cases.


 Can someone explain the original point of name expansion? Is it so that
 devices that give audio directions using text-to-speech can read fluently?
 Or was it really all about saving time?

 Because there are other use cases where expanded names are not desirable,
 particularly in cartography. When map or screen real estate is minimal,
 expanded names can be downright detrimental to utility.


 Sounds like a problem for the renderer to solve.  It's possible for
 renderers to easily create abbreviations when full words are not desired,
 but impossible for automated translation and renderers to expand
 abbreviations accurately.


I *guess*, but that seems unrealistic expectation to put on GPS hardware
manufacturers. Particularly if name expansion is inappropriate in one town,
but perfectly appropriate in another, and usual practice is to load a large
area (like a whole state or region) into a GPS device. How woud a device
renderer know to even try to distinguish across community lines?

From the user perspective it would be nicer if the names in the data set
correspond to the actual street sign names. In Portland the street name is
Tillamook and if I am on NE Tillamook that just helps me know the
quadrant of town. Northeast on it's own doesn't tell me anything if I
can't see the rest of the street name.

This example feels more like tag for reality, vs tag for the renderer
argument, and the short prefixes feel more like reality in Portland, but
maybe that's just me...

I do see the value if text-to-speech is the real reason this was done
though.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] What does the community want from a US local chapter?

[TC Haddad]

If it hasn't been mentioned already, I think you should add help to
organize SOTM-US each year (or whatever time interval is appropriate).

Tanya

On Fri, Sep 30, 2011 at 7:25 AM, Richard Weait rich...@weait.com wrote:

I'd like to see more discussion and guidance for the US local chapter.

 So, questions for the community:

 1) What would you like to see the US local chapter do?

 2) Why should this be done by the local chapter, and not by individual
 mappers?

 3) Why should this be done by the local chapter and not by the OSMF?

 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] NOAA Composite Shoreline

[TC Haddad]

As with everything, proceed with caution. The metadata for that layer states:

These data were automated to provide a suitable geographic
information system (GIS) data layer depicting the historical shoreline
for the United States. These data are derived from shoreline data that
were produced by the NOAA National Ocean Service including its
predecessor agencies

Checking it against other shorelines in my area (Oregon coast) shows
that most of the river mouths are depicted in this layer before they
had jetties, and areas of high erosion/accretion are substantially
different. Also in one location (-124.286565  42.042545) it is showing
an ocean pier that absolutely does not exist today. One nice thing is
that it has a field called SURVEYDATE that reports that that
particular part of the composite shoreline dates from 01/01/1928
so I'd pay attention to that field if you're wondering about if the
data is worth the effort for your area...

Tanya

On Wed, Jul 13, 2011 at 12:07 PM, Josh Doe j...@joshdoe.com wrote:
 On Wed, Jul 13, 2011 at 3:01 PM, Clifford Snow cliff...@snowandsnow.us
 wrote:


 On Wed, Jul 13, 2011 at 11:47 AM, Josh Doe j...@joshdoe.com wrote:

 Has anyone looked at the NOAA Composite Shoreline? It seems to have much
 better accuracy (as in orders of magnitude better) than the PGS shoreline
 that was imported, at least for the small portion I checked in Virginia.
 Unless there are better sources, I'll probably use this to fixup Virginia's
 coast piece by piece in JOSM at some point.

 Can you point me to the NOAA Composite Shoreline?

 Oops, forgot a link:
 http://shoreline.noaa.gov/data/datasheets/composite.html

 It's available as a single 200MB shapefile:
 http://shoreline.noaa.gov/data/datasheets/noaa_composite.zip

 All the other federal government shoreline datasets are listed here:
 http://shoreline.noaa.gov/index.html

 -Josh

 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us



___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us