Re: [Talk-us] GNIS?

[Bryce Nesbitt]

On Sun, Jun 16, 2013 at 4:20 PM, Thomas Colson wrote:

> Is it preferable to keep the original GNIS tags if updating a GNIS object
> in
> OSM?


I preserve the GNIS id number, even if I convert the feature from node to
way (or vice versa).
I do this not so much for later conflation, but as it acts effectively as a
"source" tag, adding useful
richness to the node history.

The GNIS import created many duplicates: there I tend to merge tags rather
than delete information
someone may have a use for in the future.  We're not sort of disk space,
and it's hard to predict
what's useful later.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Neighborhoods / Zillow

[Bryce Nesbitt]

On Sat, Jun 15, 2013 at 7:22 PM, Nathan Mills  wrote:

> The sort of signs in the link below are precisely the sort of thing we put
> in OSM, or at least have historically.
> https://www.cityoftulsa.org/**community-programs/**
> neighborhoods/neighborhood-**sign-guide.aspx


There is certainly no problem mapping the *sign*.
The sign is verifiable & objective.
And the data is indexable and useful to map users, not just to mappers.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Road Restriction: No RV's?

[Bryce Nesbitt]

On Sun, Jun 16, 2013 at 3:27 PM, Thomas Colson wrote:

> Is there a tag equivalent for a road restriction that would imply no
> Recreational Vehicles/Motor Homes/Buses?
>

Are you talking RV's as "not advised" or "prohibited"?
And how about trucks with a given  kingpin-to-rearmost-axle (KPRA) distance?
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS?

[Mike N]

On 6/16/2013 7:20 PM, Thomas Colson wrote:

Is it preferable to keep the original GNIS tags if updating a GNIS object in
OSM?


 It's fine to leave or delete all GNIS tags.  If creating an object 
with an area, I just copy all GNIS tags and merge tags from duplicate 
objects.


  At one time, there was a plan for the USGS to use updated GNIS from 
OSM, but I think that plan has become stranded on the island of license 
incompatibility.   Therefore, even the GNIS id tag isn't critical IMO.



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

Re: [Talk-us] GNIS?

[Clifford Snow]

On Mon, Jun 17, 2013 at 2:49 AM, Mike N  wrote:

> At one time, there was a plan for the USGS to use updated GNIS from OSM,
> but I think that plan has become stranded on the island of license
> incompatibility.   Therefore, even the GNIS id tag isn't critical IMO.


At last years SOTM-US conference, USGS showed a pilot  program using a
modified version of Potlatch2 to update GNIS database with volunteers. If
they use this plan, the id tag could be used to compare OSM with the new
data. It would us to compare the existing OSM data with the new GNIS data.
For now I would suggest leaving that tag in OSM.


-- 
Clifford

OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS?

[the Old Topo Depot]

Jim McAndrew, one of the US Board Members, gave a presentation on the USGS
National Map Corps project status on June 9th (
http://stateofthemap.us/sunday.html#schedule/sunday/usgs-national-map-corps).
 I recommend the community work with Jim and his colleagues to ensure the
most effective exchange of data updates between OSM and the USGS mapping
community.




On Mon, Jun 17, 2013 at 7:56 AM, Clifford Snow wrote:

>
> On Mon, Jun 17, 2013 at 2:49 AM, Mike N  wrote:
>
>> At one time, there was a plan for the USGS to use updated GNIS from OSM,
>> but I think that plan has become stranded on the island of license
>> incompatibility.   Therefore, even the GNIS id tag isn't critical IMO.
>
>
> At last years SOTM-US conference, USGS showed a pilot  program using a
> modified version of Potlatch2 to update GNIS database with volunteers. If
> they use this plan, the id tag could be used to compare OSM with the new
> data. It would us to compare the existing OSM data with the new GNIS data.
> For now I would suggest leaving that tag in OSM.
>
>
> --
> Clifford
>
> OpenStreetMap: Maps with a human touch
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
>


-- 
John Novak
585-OLD-TOPOS (585-653-8676)
http://www.linkedin.com/in/johnanovak/
OSM ID:oldtopos
OSM Heat Map: http://yosmhm.neis-one.org/?oldtopos
OSM Edit Stats:http://hdyc.neis-one.org/?oldtopos
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS?

[Mike N]

On 6/17/2013 10:56 AM, Clifford Snow wrote:

At last years SOTM-US conference, USGS showed a pilot  program using a
modified version of Potlatch2 to update GNIS database with volunteers.
If they use this plan, the id tag could be used to compare OSM with the
new data. It would us to compare the existing OSM data with the new GNIS
data. For now I would suggest leaving that tag in OSM.


 I got a chance to catch his presentation on this year's video (Thanks 
SOTM-US video production crew and posters!).   I will be looking forward 
to being able to use the results of MapCorps efforts.


  I agree that leaving the tag in OSM is the best course, but it's 
likely to only be an advisory clue when merging data, if it's used at all:


 -  Many times, local churches or schools had a new building built 
anywhere from a mile away to across town.  If the name was retained, I 
simply moved the GNIS node.   The updated GNIS information may simply 
mark this as XYZ school (historical) and keep its position.Or they 
may delete it and assign a new ID to whatever the building is now used 
for.


 - If someone has already added a node or way representing the new GNIS 
object, the conflation process still needs to handle the case of same or 
similar name but no GNIS ID.




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

Re: [Talk-us] Neighborhoods / Zillow

[John F. Eldredge]

In Nashville, TN, where I live, most of the city's growth has been since World 
War II, and hence suburban in nature.  Some subdivisions have permanent signs, 
some don't.   Some have a discernable tree structure, some have a loose grid, a 
few areas have a rectilinear grid.  Plus, some areas combine later development 
with what used to be small towns, swallowed up as the city expanded.  Some 
areas have names picked by a modern developer, some are named after these old 
towns, and at least one area is named after a particular pre-Civil-War mansion 
that, for decades, was the largest house in the neighborhood.  So, the 
neighborhood naming scheme is best described as "all of the above".


Minh Nguyen  wrote:

> I've driven all over Cincinnati's northeastern suburbs collecting 
> subdivision names, the ones that adorn signs and gates at subdivision 
> entrances. I used to hear school bus drivers use the same names when 
> communicating their progress over the radio. These subdivisions are
> only 
> meaning of "neighborhood" that makes sense in an area with endless
> sprawl.
> 
> Upon returning to my armchair, I trace individual landuse=residential 
> polygons for each of these subdivisions. It's easy to discern the 
> boundaries because most subdivisions aren't connected. Where they are,
> 
> one can easily spot where sidewalks end, one cookie cutter
> architecture 
> gives way to another, or the pavement quality changes -- some cities 
> repave one whole subdivision at a time.
> 

-- 
John F. Eldredge -- j...@jfeldredge.com
"Reserve your right to think, for even to think wrongly is better than not to 
think at all." -- Hypatia of Alexandria

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

Re: [Talk-us] GNIS?

[Bryce Nesbitt]

On Mon, Jun 17, 2013 at 7:56 AM, Clifford Snow wrote:
>
> At last years SOTM-US conference, USGS showed a pilot  program using a
> modified version of Potlatch2 to update GNIS database with volunteers. If
> they use this plan, the id tag could be used to compare OSM with the new
> data. It would us to compare the existing OSM data with the new GNIS data.
> For now I would suggest leaving that tag in OSM.
>

Any conflation (matting of new data to OSM data) should use multiple fuzzy
clues: location, name, type.
The gnis id tag is useful as a fuzzy clue.
Every clue is useful.

I think *keeping* the tag makes sense, even though *depending* on the tag
would be asking too much.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Neighborhoods / Zillow

[stevea]

On 2013-06-15 6:51 PM, Serge Wroclawski wrote:

On Sat, Jun 15, 2013 at 6:35 PM, stevea  wrote:


For the former, I don't need a painted line on the ground, just what the
City GIS department publishes on the open Internet, after these
lines/polygons/neighborhood boundaries were reached by public process.


There is a growing number of OSM folks in the United States (myself
included) who believe that government provided boundry data should be
used for data products such as rendered maps and geocoders, but do not
belong in OSM's core dataset (which is built around the idea of
improvements based on local, verifiable observation).

The result is that for data of the type you're talking about
(government provided polygons), I think they'd be best provided as a
third party service.

And for the more subjective neighborhood boundaries, by its nature, it
doesn't belong in OSM either.


Minh Nguyen  writes:

But there's a third kind of neighborhood data: objective data that 
doesn't come from a government database.

(and continues):
Different cities developed in different ways. OSM should encourage 
neighborhood data curated by locals aware of the city's history. 
Perhaps this kind of data is more suitable for display, while 
algorithmic solutions may be better for geocoding.


In my opinion, Minh's thoughtful discussion here is an outstanding 
(short) treatise supporting reasonable wide definitions (nodes, 
polygons, government data, directly "on the ground" observable data: 
differing histories of city and neighborhood development needing a 
rich set of multiple syntax) for neighborhood data in OSM.


Again, this is not a "one solution fits all situations" problem, in 
this thread we have seen that over and over.  Let's continue to allow 
OSM to capture observable data (including aerial and satellite 
imagery) and local government-produced data alike, whether as nodes 
or polygons, as appropriate.  Many other features allow for both 
types of data structures, neighborhoods really are no different.


Algorithms which "simply" (wrongly, in many cases) extrapolate a 
neighborhood derived from a centroid deserve what they get:  often 
erroneous answers as to the question "is THIS in this neighborhood?" 
Let them tune their geocoding algorithms to be more clever instead, 
and answers will surely become more correct.


SteveA
California

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

[Talk-us] ref tags

[Martijn van Exel]

Hi all,

I wanted to get an opinion on the right place for 'ref' tags on numbered
routes.

>From what I understand, osm2pgsql and the downstream rendering process uses
the ref tags on the way object to render highway 'shields'.

The following example corroborates this. Consider this (long) way:

http://www.openstreetmap.org/browse/way/13649057

See how this segment has no 'shields' on the map because the way itself has
no ref tag:

http://www.openstreetmap.org/?lat=32.5419&lon=-89.4744&zoom=13&layers=M

Even though the way is part of the properly tagged relation

http://www.openstreetmap.org/browse/relation/23246

I see two issues here:

1) Information already present in the relation object being duplicated on
the way to satisfy the renderer
2) Incomplete coverage of ref information on ways

I don't think we can solve 1) in the short term. There are likely many,
many numbered route networks in the world that are poorly covered by
relations, because the renderer does not encourage it, because relations
were introduced after a lot of numbered routes were already tagged before
the arrival of relations, because the wiki is ambiguous, perhaps other
reasons.

There are perhaps a few thousand ways in the U.S. that are part of a
numbered route, yet do not have ref tags on the way. My question is: how
should we deal with these?

My proposal is to 'fill the gaps' by manually tagging these ways using the
existing conventions for route relation ref tagging ('US 98', 'I 20', 'MS
467', etc.) wherever this information can be derived from an existing route
relation. We have folks here at Telenav willing to spend some cycles on
this, but I want to see if this is a sane approach before we do anything.
-- 
Martijn van Exel
http://oegeo.wordpress.com/
http://openstreetmap.us/
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Neighborhoods / Zillow

[Anthony]

On 2013-06-15 6:51 PM, Serge Wroclawski wrote:

> There is a growing number of OSM folks in the United States (myself
>>> included) who believe that government provided boundry data should be
>>> used for data products such as rendered maps and geocoders, but do not
>>> belong in OSM's core dataset (which is built around the idea of
>>> improvements based on local, verifiable observation).
>>>
>>
Stevea replied:

> Again, this is not a "one solution fits all situations" problem, in this
> thread we have seen that over and over.  Let's continue to allow OSM to
> capture observable data (including aerial and satellite imagery) and local
> government-produced data alike, whether as nodes or polygons, as
> appropriate.  Many other features allow for both types of data structures,
> neighborhoods really are no different.
>

One thing that seems to be missing from Serge's analysis is that much of
government collected data is based on local, verifiable observation.

If the government decides that "Blah Neighborhood" consists of the blocks
bounded by Foo Street, Bar Road, Whatever River, and Whichamajig Railroad,
and then they create a polygon geocoding that, the government has used
local, verifiable observation to create that polygon.  And they aren't
going to get it exactly right.  OSM mappers very well might come along and
fix the border which corresponds to Whatever River, for instance.

I'm not aware of any government node, way, or polygon data in OSM, whose
presence is not disputed, where there isn't some tie to local, verifiable,
observable, on-the-ground features.  State borders are not truly defined by
latitudes and longitudes.  That is to say, even in places where a border is
historically defined as "the 40th parallel" or some specific latitude, the
true legal border does not lie exactly in that location.  Someone may have
historically measured the border incorrectly, and that measurement sticks
as the legal definition.  The latitude of the border may have shifted over
time due to movements in the underlying ground or continental plate.  I
can't think of any border which is legally defined in terms of latitude and
longitude.  And any border which isn't legally defined in terms of latitude
and longitude can be surveyed based on local, verifiable observation.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Neighborhoods / Zillow

[Anthony]

It's not about mapping the sign, it's about mapping the neighborhood based
on the sign.

We don't map speed limit signs, we map the speed limits on the roads based
on the signs.  We don't map interstate signs, we map the name of the
interstate.  We don't map individual trees, we map forests.  We don't map
"keep out, military area" signs, we map military areas.


On Mon, Jun 17, 2013 at 3:05 AM, Bryce Nesbitt  wrote:

>
>
> On Sat, Jun 15, 2013 at 7:22 PM, Nathan Mills  wrote:
>
>> The sort of signs in the link below are precisely the sort of thing we
>> put in OSM, or at least have historically.
>> https://www.cityoftulsa.org/**community-programs/**
>> neighborhoods/neighborhood-**sign-guide.aspx
>
>
> There is certainly no problem mapping the *sign*.
> The sign is verifiable & objective.
> And the data is indexable and useful to map users, not just to mappers.
>
> ___
> 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] Cleaning up California FMMP "residential"

[Paul Norman]

Having received nothing but positive feedback I'll put figuring out how to
do this on my to-do list if there are no objections.  I may come back for
more consultation if I feel it necessary after looking at the technical
steps. I won't conduct this edit before Friday at the absolute soonest.

We probably need to have a bigger look at cleaning up California landuse
imports, there is some weird and wrong stuff there, but that's a wider
discussion that doesn't need to stop us from removing the clearly wrong
stuff.

> From: Paul Norman [mailto:penor...@mac.com]
> Sent: Friday, June 14, 2013 3:29 PM
> To: OpenStreetMap US Talk
> Subject: [Talk-us] Cleaning up California FMMP "residential"
> 
> I've been doing some California landuse and have come across a lot of
> landuse=residential imported from FMMP which is clearly wrong. The
> landuse=residential covers entire cities, including commercial,
> industrial, retail, parks, schools, golf courses, airports, and pretty
> much anything within city limits.
> 
> It's hard to be certain because whatever was done doesn't match the
> documentation at http://wiki.openstreetmap.org/wiki/California_Farms but
> it appears that data corresponding to any urban area was imported as
> landuse=residential.
> 
> Given that this is a systemic problem with this imported data and the
> problem originates with the import conversion, I think the best approach
> to fix it is a mechanical edit. Given that the data is 1.5 years old
> without being cleaned up, I believe it is the best option.
> 
> To this end, I propose removing v1 imported ways/multipolygons from FMMP
> with FMMP_modified=no, FMMP_reviewed=no, landuse=residential, and either
> description=other land or description=urban land, starting with ways >
> about
> 500 000 square Mercator meters (exact value subject to change).
> 
> This would be about 750 areas.
> 
> There are about 3000 smaller areas that would need dealing with later,
> but it'd be nice to get the large hard to edit ones cleaned up first.



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

Re: [Talk-us] ref tags

[Jason Remillard]

Why not just patch osm2pgsql? It seems like the right place for this
is on the relation.

On Mon, Jun 17, 2013 at 4:03 PM, Martijn van Exel  wrote:
> Hi all,
>
> I wanted to get an opinion on the right place for 'ref' tags on numbered
> routes.
>
> From what I understand, osm2pgsql and the downstream rendering process uses
> the ref tags on the way object to render highway 'shields'.
>
> The following example corroborates this. Consider this (long) way:
>
> http://www.openstreetmap.org/browse/way/13649057
>
> See how this segment has no 'shields' on the map because the way itself has
> no ref tag:
>
> http://www.openstreetmap.org/?lat=32.5419&lon=-89.4744&zoom=13&layers=M
>
> Even though the way is part of the properly tagged relation
>
> http://www.openstreetmap.org/browse/relation/23246
>
> I see two issues here:
>
> 1) Information already present in the relation object being duplicated on
> the way to satisfy the renderer
> 2) Incomplete coverage of ref information on ways
>
> I don't think we can solve 1) in the short term. There are likely many, many
> numbered route networks in the world that are poorly covered by relations,
> because the renderer does not encourage it, because relations were
> introduced after a lot of numbered routes were already tagged before the
> arrival of relations, because the wiki is ambiguous, perhaps other reasons.
>
> There are perhaps a few thousand ways in the U.S. that are part of a
> numbered route, yet do not have ref tags on the way. My question is: how
> should we deal with these?
>
> My proposal is to 'fill the gaps' by manually tagging these ways using the
> existing conventions for route relation ref tagging ('US 98', 'I 20', 'MS
> 467', etc.) wherever this information can be derived from an existing route
> relation. We have folks here at Telenav willing to spend some cycles on
> this, but I want to see if this is a sane approach before we do anything.
> --
> Martijn van Exel
> http://oegeo.wordpress.com/
> http://openstreetmap.us/
>
> ___
> 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] ref tags

[Martijn van Exel]

Because, as I understand it, route relations are not used as extensively in
some regions / countries as they are here in the U.S. and we cannot impose
this reliance on relationships for numbered route relations on everyone.
Perhaps if we make it a switch / option in osm2pgsql so folks can choose
based on their local situation?


On Mon, Jun 17, 2013 at 3:15 PM, Jason Remillard
wrote:

> Why not just patch osm2pgsql? It seems like the right place for this
> is on the relation.
>
> On Mon, Jun 17, 2013 at 4:03 PM, Martijn van Exel  wrote:
> > Hi all,
> >
> > I wanted to get an opinion on the right place for 'ref' tags on numbered
> > routes.
> >
> > From what I understand, osm2pgsql and the downstream rendering process
> uses
> > the ref tags on the way object to render highway 'shields'.
> >
> > The following example corroborates this. Consider this (long) way:
> >
> > http://www.openstreetmap.org/browse/way/13649057
> >
> > See how this segment has no 'shields' on the map because the way itself
> has
> > no ref tag:
> >
> > http://www.openstreetmap.org/?lat=32.5419&lon=-89.4744&zoom=13&layers=M
> >
> > Even though the way is part of the properly tagged relation
> >
> > http://www.openstreetmap.org/browse/relation/23246
> >
> > I see two issues here:
> >
> > 1) Information already present in the relation object being duplicated on
> > the way to satisfy the renderer
> > 2) Incomplete coverage of ref information on ways
> >
> > I don't think we can solve 1) in the short term. There are likely many,
> many
> > numbered route networks in the world that are poorly covered by
> relations,
> > because the renderer does not encourage it, because relations were
> > introduced after a lot of numbered routes were already tagged before the
> > arrival of relations, because the wiki is ambiguous, perhaps other
> reasons.
> >
> > There are perhaps a few thousand ways in the U.S. that are part of a
> > numbered route, yet do not have ref tags on the way. My question is: how
> > should we deal with these?
> >
> > My proposal is to 'fill the gaps' by manually tagging these ways using
> the
> > existing conventions for route relation ref tagging ('US 98', 'I 20', 'MS
> > 467', etc.) wherever this information can be derived from an existing
> route
> > relation. We have folks here at Telenav willing to spend some cycles on
> > this, but I want to see if this is a sane approach before we do anything.
> > --
> > Martijn van Exel
> > http://oegeo.wordpress.com/
> > http://openstreetmap.us/
> >
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-us
> >
>



-- 
Martijn van Exel
http://oegeo.wordpress.com/
http://openstreetmap.us/
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] ref tags

[Paul Johnson]

The excuse I've heard is that European countries "don't have
concurrencies."  Which conveniently ignores the E roads...


On Mon, Jun 17, 2013 at 6:05 PM, Martijn van Exel  wrote:

> Because, as I understand it, route relations are not used as extensively
> in some regions / countries as they are here in the U.S. and we cannot
> impose this reliance on relationships for numbered route relations on
> everyone. Perhaps if we make it a switch / option in osm2pgsql so folks can
> choose based on their local situation?
>
>
> On Mon, Jun 17, 2013 at 3:15 PM, Jason Remillard <
> remillard.ja...@gmail.com> wrote:
>
>> Why not just patch osm2pgsql? It seems like the right place for this
>> is on the relation.
>>
>> On Mon, Jun 17, 2013 at 4:03 PM, Martijn van Exel  wrote:
>> > Hi all,
>> >
>> > I wanted to get an opinion on the right place for 'ref' tags on numbered
>> > routes.
>> >
>> > From what I understand, osm2pgsql and the downstream rendering process
>> uses
>> > the ref tags on the way object to render highway 'shields'.
>> >
>> > The following example corroborates this. Consider this (long) way:
>> >
>> > http://www.openstreetmap.org/browse/way/13649057
>> >
>> > See how this segment has no 'shields' on the map because the way itself
>> has
>> > no ref tag:
>> >
>> > http://www.openstreetmap.org/?lat=32.5419&lon=-89.4744&zoom=13&layers=M
>> >
>> > Even though the way is part of the properly tagged relation
>> >
>> > http://www.openstreetmap.org/browse/relation/23246
>> >
>> > I see two issues here:
>> >
>> > 1) Information already present in the relation object being duplicated
>> on
>> > the way to satisfy the renderer
>> > 2) Incomplete coverage of ref information on ways
>> >
>> > I don't think we can solve 1) in the short term. There are likely many,
>> many
>> > numbered route networks in the world that are poorly covered by
>> relations,
>> > because the renderer does not encourage it, because relations were
>> > introduced after a lot of numbered routes were already tagged before the
>> > arrival of relations, because the wiki is ambiguous, perhaps other
>> reasons.
>> >
>> > There are perhaps a few thousand ways in the U.S. that are part of a
>> > numbered route, yet do not have ref tags on the way. My question is: how
>> > should we deal with these?
>> >
>> > My proposal is to 'fill the gaps' by manually tagging these ways using
>> the
>> > existing conventions for route relation ref tagging ('US 98', 'I 20',
>> 'MS
>> > 467', etc.) wherever this information can be derived from an existing
>> route
>> > relation. We have folks here at Telenav willing to spend some cycles on
>> > this, but I want to see if this is a sane approach before we do
>> anything.
>> > --
>> > Martijn van Exel
>> > http://oegeo.wordpress.com/
>> > http://openstreetmap.us/
>> >
>> > ___
>> > Talk-us mailing list
>> > Talk-us@openstreetmap.org
>> > http://lists.openstreetmap.org/listinfo/talk-us
>> >
>>
>
>
>
> --
> Martijn van Exel
> http://oegeo.wordpress.com/
> http://openstreetmap.us/
>
> ___
> 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] ref tags

[Jason Remillard]

Hi,

If the way is part of relation that has a ref, and the way itself does
not have a ref, then the relation ref should propagate to the way. If
the way has a ref, then that is what should be used regardless if its
in a relation or not.

Would that break anybody?

Thanks
Jason.


On Mon, Jun 17, 2013 at 7:05 PM, Martijn van Exel  wrote:
> Because, as I understand it, route relations are not used as extensively in
> some regions / countries as they are here in the U.S. and we cannot impose
> this reliance on relationships for numbered route relations on everyone.
> Perhaps if we make it a switch / option in osm2pgsql so folks can choose
> based on their local situation?
>
>
> On Mon, Jun 17, 2013 at 3:15 PM, Jason Remillard 
> wrote:
>>
>> Why not just patch osm2pgsql? It seems like the right place for this
>> is on the relation.
>>
>> On Mon, Jun 17, 2013 at 4:03 PM, Martijn van Exel  wrote:
>> > Hi all,
>> >
>> > I wanted to get an opinion on the right place for 'ref' tags on numbered
>> > routes.
>> >
>> > From what I understand, osm2pgsql and the downstream rendering process
>> > uses
>> > the ref tags on the way object to render highway 'shields'.
>> >
>> > The following example corroborates this. Consider this (long) way:
>> >
>> > http://www.openstreetmap.org/browse/way/13649057
>> >
>> > See how this segment has no 'shields' on the map because the way itself
>> > has
>> > no ref tag:
>> >
>> > http://www.openstreetmap.org/?lat=32.5419&lon=-89.4744&zoom=13&layers=M
>> >
>> > Even though the way is part of the properly tagged relation
>> >
>> > http://www.openstreetmap.org/browse/relation/23246
>> >
>> > I see two issues here:
>> >
>> > 1) Information already present in the relation object being duplicated
>> > on
>> > the way to satisfy the renderer
>> > 2) Incomplete coverage of ref information on ways
>> >
>> > I don't think we can solve 1) in the short term. There are likely many,
>> > many
>> > numbered route networks in the world that are poorly covered by
>> > relations,
>> > because the renderer does not encourage it, because relations were
>> > introduced after a lot of numbered routes were already tagged before the
>> > arrival of relations, because the wiki is ambiguous, perhaps other
>> > reasons.
>> >
>> > There are perhaps a few thousand ways in the U.S. that are part of a
>> > numbered route, yet do not have ref tags on the way. My question is: how
>> > should we deal with these?
>> >
>> > My proposal is to 'fill the gaps' by manually tagging these ways using
>> > the
>> > existing conventions for route relation ref tagging ('US 98', 'I 20',
>> > 'MS
>> > 467', etc.) wherever this information can be derived from an existing
>> > route
>> > relation. We have folks here at Telenav willing to spend some cycles on
>> > this, but I want to see if this is a sane approach before we do
>> > anything.
>> > --
>> > Martijn van Exel
>> > http://oegeo.wordpress.com/
>> > http://openstreetmap.us/
>> >
>> > ___
>> > Talk-us mailing list
>> > Talk-us@openstreetmap.org
>> > http://lists.openstreetmap.org/listinfo/talk-us
>> >
>
>
>
>
> --
> Martijn van Exel
> http://oegeo.wordpress.com/
> http://openstreetmap.us/

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

Re: [Talk-us] ref tags

[Richard Welty]

On 6/17/13 10:19 PM, Jason Remillard wrote:

Hi,

If the way is part of relation that has a ref, and the way itself does
not have a ref, then the relation ref should propagate to the way. If
the way has a ref, then that is what should be used regardless if its
in a relation or not.

Would that break anybody?


it's an ok temporary expedient.

ref tags on ways are erratic in the US, and in the long term we should
move to full use of relations and removal of ref tags from ways. that will
take quite a while, but it should be the goal state.

richard


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

Re: [Talk-us] ref tags

[Paul Johnson]

Kind of looking forward to that, too, since it would allow more accurately
mapping situations like Oregon, where State Highways are the original
numbers used on trailblazers and what ODOT refers to roads it's roadways
as, as opposed to the State Routes that usually traverse multiple state
highways.  Granted, some of these coincide, largely with the state highways
and state routes adopted in the last 2 decades, such as SR 120/SH 120.
 Others are a bit more murky.  For example, SH 1/1C/1W/1E coincide with
varying parts of Interstate 5, various ocean beaches open to driving that
have not been assigned a state route but are part of the highway system, SR
99W, SR 99E, SR 99 and more...


On Mon, Jun 17, 2013 at 9:57 PM, Richard Welty wrote:

> On 6/17/13 10:19 PM, Jason Remillard wrote:
>
>> Hi,
>>
>> If the way is part of relation that has a ref, and the way itself does
>> not have a ref, then the relation ref should propagate to the way. If
>> the way has a ref, then that is what should be used regardless if its
>> in a relation or not.
>>
>> Would that break anybody?
>>
>>  it's an ok temporary expedient.
>
> ref tags on ways are erratic in the US, and in the long term we should
> move to full use of relations and removal of ref tags from ways. that will
> take quite a while, but it should be the goal state.
>
> richard
>
>
>
> __**_
> 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] Neighborhoods / Zillow

[Elliott Plack]

What a fantastic post! I am a neighborhood guru, as mapping subdivisions is
part of my job description at Baltimore County Government. i have several
years experience mapping neighborhoods in the legal sense in an ESRI GIS
environment, and have translated some of that to OSM in my spare time. When
our data goes CC0, I'm going to look into making an 'imagery' layer of plat
outlines so that people can trace them if they want.

A few quick points (some are not unique):

* Neighborhood can mean a fluid place OR a platted subdivision with defined
legal boundaries. I find the former to be the case in cities where land was
not conveyed by plat in 1600-1900s, but rather by deed or some other asinine
instrument. The large tracts that became city neighborhoods don't tend to
have a definitive plat thus people come up with their own names. Meanwhile,
the latter is generally the case in suburbs, especially the ones that sprang
up after WW2. By then, plats were the requirement, not just the norm, and
developers thought of cute names like 'Placid Acres' which stuck with the
community. HOAs reinforce this.
* place=neighborhood vs place=hamlet: The TIGER import as I understand it
uses the place=hamlet (silly british name). PLACE=NEIGHBORHOOD IS NOT
RENDERED (https://trac.openstreetmap.org/ticket/4191) and thus I haven't
changed place=hamlets to neighborhood here. Hamlet has no meaning in
Baltimore except perhaps where Robin Hood might live.
* It makes sense that Zillow has the good data because real estate is all
about location, and everyone wants to be in the desirable 'neighborhood.'
Many of these boundaries are set by govs. People don't always agree, and new
buyers may find themselves on the 'wrong side of the tracks' despite the
listing being in the good area.

That's all for now.
-Elliott



-
http://about.me/elliottp | http://www.openstreetmap.org/user/ElliottPlack
--
View this message in context: 
http://gis.19327.n5.nabble.com/Neighborhoods-Zillow-tp5764954p5765851.html
Sent from the USA mailing list archive at Nabble.com.

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

Re: [Talk-us] Cleaning up California FMMP "residential"

[Nathan Mixter]

As the original importer of this data, I support Paul's proposal to
selectively delete the larger residential areas, which mostly are too broad
to be in OSM. I know the farm data has its problems, especially in the
earlier counties where I didn't fully realize how to use techniques to
fully optimize the data and split it up more first. But there is a lot of
good useful data mixed in with the bad data. The strength of the data is
the farms and these data are generally high quality. People have expressed
to me that the data is hard to edit in the areas that it is too vast, and I
do apologize for the extra work this has caused. Originally I left in a lot
of what FMMP defined as "urban land." These often included a wide variety
of features that were split apart a lot better in later imports done.

For better or for worse, California is no longer a barren wilderness but
has blossomed into a flower full of color and life. I always am open to
comments and critisms and working with others to make the data better.

Nathan


> --
>
> Message: 1
> Date: Fri, 14 Jun 2013 15:28:50 -0700
> From: Paul Norman 
> To: OpenStreetMap US Talk 
> Subject: [Talk-us] Cleaning up California FMMP "residential"
> Message-ID: <005901ce694e$8c1b2d80$a4518880$@mac.com>
> Content-Type: text/plain; charset=us-ascii
>
> I've been doing some California landuse and have come across a lot of
> landuse=residential imported from FMMP which is clearly wrong. The
> landuse=residential covers entire cities, including commercial, industrial,
> retail, parks, schools, golf courses, airports, and pretty much anything
> within city limits.
>
> It's hard to be certain because whatever was done doesn't match the
> documentation at http://wiki.openstreetmap.org/wiki/California_Farms but
> it
> appears that data corresponding to any urban area was imported as
> landuse=residential.
>
> Given that this is a systemic problem with this imported data and the
> problem originates with the import conversion, I think the best approach to
> fix it is a mechanical edit. Given that the data is 1.5 years old without
> being cleaned up, I believe it is the best option.
>
> To this end, I propose removing v1 imported ways/multipolygons from FMMP
> with FMMP_modified=no, FMMP_reviewed=no, landuse=residential, and either
> description=other land or description=urban land, starting with ways >
> about
> 500 000 square Mercator meters (exact value subject to change).
>
> This would be about 750 areas.
>
> There are about 3000 smaller areas that would need dealing with later, but
> it'd be nice to get the large hard to edit ones cleaned up first.
>
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us