[Talk-us] A P2 deployment with a NHD layer

[Paul Norman]

For the last couple weeks I've been working on getting NHD into P2 and I've
now got a working preview at
http://took.paulnorman.ca/potlatch2/potlatch2.html

This P2 instance will take you to the east side of Missouri in the 0714
basin. This is the south end of the 07 region and covers part of Illinois.

The NHD layer is being served by snapshot-server off of my home computer so
it may be slow as it's not properly deployed and it's behind a home internet
connection.

With the styles that come up by default the gray lines with orange outlines
are features from NHD which aren't marked as completed and the fainter gray
with green have been marked as completed. I've marked some ponds as
completed where there weren't any signs of them on the imagery.

You can change the NHD style by going to Background -> Load Vector File.

The NHD tagging doesn't represent a finished product. 

A few warnings:

- NHD represents riverbanks as giant polygons. These slow down my server and
it may take a while to respond. That's why I chose this starting point to
view, there aren't any giant ways right beside it.

- The tagging is not yet complete. The main impact in this basin is that
some points may have unconverted data. I believe all ways will be
appropriately tagged.

- The geometries are not simplified.

- Snapshot-server doesn't fit nicely into any of the traditional
classifications of imports. In any case, at this point it's a proof of
concept.

- I may at times randomly shut off the server as I do work with it.

- There may be some scaling issues with snapshot-server

- The default cyclestreets style for the NHD layer is not great

More information on the P2 merging tool can be be found at
http://wiki.openstreetmap.org/wiki/Potlatch_2_merging_tool



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

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Bill R. WASHBURN]

Since my email client sent my messages direct to the OP and not to the
list, I'm going to resend them:

First response:
-

We have to be careful that the availability of this granularity doesn't
insecure the road names, specifically in cases where part of the road name
could be confused as a prefix or suffix. Let me throw a few usage cases for
the metro Atlanta area out to illustrate.

Cobb county uses the quadrant suffix system where everything in the part of
the county closest to the city of Atlanta gets a SW suffix. Most of the
time, locals ignore the suffix. Separating the suffix makes sense in this
context since it is treated as secondary information by locals.

One place where I can see a non-invasive goofing up our local roads is
North Decatur Road. That road is named after the North Decatur area through
which it runs, as best I can tell from my local knowledge, therefore making
"North" part of the name of the road and not a prefix. Locals, when giving
directions, treat the name as North Decatur, always including, North as
part of the name. You'll never hear a local send someone to Decatur Road.
Breaking North away from Decatur does not make sense in this context (and
the local transit agency confuses locals, me included, by making this
mistake on the time table charts on their website).

Similarly, The By Way is a road for which separating the prefix, "The," the
name, "By," and the road type, "Way," doesn't make grammatical sense and
the road is not mentioned without the while name. As a local mapper, I
would not want this name broken up since, in our hyper-local context, it
does not make sense to do so.

(Compare the second and third cases to East Ponce de Leon Avenue, locally
shortened to Ponce or Ponce de Leon. The directional prefix and road type
are treated as secondary, discardable information in local speech.)

--

Second response:
--

I'm less than enthusiastic about regionally specific tags but it's feasible
to me that other areas may find this proposal useful.

Would you be opposed to just splitting off the directional prefixes and
suffixes, thereby leaving the road type and name prefix combined with the
name? I think, to me, that it's important to leave the information that
uniquely identified the road together. In my never-humble opinion, only
splitting out the directional would balance my concern for keeping the name
as complete as possible and splitting out the information which is,
contextually, secondary information.

-

And now an inline response:

On Sun, Nov 18, 2012 at 6:35 PM, Paul Norman  wrote:
>
> My understanding from the SOTM-US talk is that he proposes redefining what
> the name tag means and that for a street like "K Street NW" the name of
> that
> street is simply K.


If this is the reason for the change, I'm going to argue against it: to me,
the full official street name is the one with all of the prefixes and
suffixes. I can see cases, as I quoted in my first two responses, where a
distant armchair mapper with decent intentions might override local
knowledge about the word "North" in the road name "North Decatur Road." I
think that I'm of the opinion that, if this is implemented as supplementary
tags, we can display this like the tiger import tags did, breaking down the
street name into it's techical parts. The problems that this proposal might
introduce include reprogramming the navigation packages to recognize the
old way and the proposed way of structuring street names; the last thing I
need, while listening to my navigation software give directions, is to be
told, "Turn right on to By," when the correct direction is, "Turn right on
to The By Way."

I think that it's an interesting way of looking at the data, but I don't
think the current way of writing the street name introduces ambiguity.
Actually, I think the proposed way could add ambiguity for software which
is not programmed for the proposed method. Try navigating around the Metro
Atlanta area with the road name "Peachtree" separated from the road type
"Street" or "Place" or one of the other oodles of Peachtree-something
combinations (again, from software not adapted to this proposal).
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Paul Norman]

> From: Serge Wroclawski [mailto:emac...@gmail.com]
> Subject: Re: [Talk-us] Feature proposal: proposed expanded address
> tagging scheme for US
> 
> > Since local conditions vary so
> > widely across the US, having more tags gives mappers more flexibility
> > to tag what they see.
> 
> How does it give them more flexibility to tag what they see? Are you
> suggesting that this replace (rather than supplement) the "name" tag?

My understanding from the SOTM-US talk is that he proposes redefining what
the name tag means and that for a street like "K Street NW" the name of that
street is simply K.


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

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Clifford Snow]

Steve,
I suggest you start your proposal with a problem statement and then explain
how your solution solves the problem. Otherwise it looks to me to be a
solution looking for a problem. Do we have any data to suggest that the
current street addresses do not work? Why is it just a US problem?

If you provide a problem statement then we can have a discussion about 1)
is it a real problem and how big is it and 2) what is the best way to solve
the problem.

Clifford


On Sat, Nov 17, 2012 at 3:45 PM, Steven Johnson wrote:

> Hi all,
> Following up on an action from SotM-PDX, I've posted a proposal for
> expanded tagging for addresses, primarily in the US (though it may have
> application in other countries). The intent of the tags is to 1) improve
> the description of US addresses, and 2) provide greater flexibility for
> local mappers. These tags are necessary because unlike other countries, the
> US has no nationwide house numbering/street naming standard. These tags
> provide more granularity for local mappers and hopefully, will reduce much
> of the ambiguity and confusion with addresses in localities with widely
> varying address schemes.
>
> I invite your comments and discussion on the proposed tags. Thanks.
>
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/UnitedStates
>
> -- SEJ
> -- twitter: @geomantic
> -- skype: sejohnson8
>
> "Common sense is the collection of prejudices acquired by age eighteen."
> -- Einstein
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
>


-- 
Clifford

I have promised to cut down on my swearing and drinking, which I have.
 Unfortunately, this has left me dim-witted and nearly speechless. Adapted
from *The Lion* by Nelson DeMille

-or-

If you can't explain it simply, you don't understand it well enough.
 Albert Einstein
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Serge Wroclawski]

Steven,

Thanks for the reply.

More inline.

On Sun, Nov 18, 2012 at 3:08 PM, Steven Johnson  wrote:
> Richard & Serge,
>
> Thanks for the comments. Let me see if I can clarify...
>
> The problem: Unlike other (mostly European) countries, there are at least 4
> street naming schemes, and 2 property numbering schemes in the US. This
> makes a set of one-size-fits-all tags for addresses both unwieldy,
> imprecise, and ambiguous.
>
> It forces local mappers to overload the
> addr:street tag with directional prefixes, suffixes, and street types. It
> perpetuates ambiguity and lessens the value of the data, as well as
> constraining mappers from adequately describing local conditions.

You gave one example, which I'll address later in the mail, but more
examples makes your case more salient.

> The solution: splitting out the tags has several advantages:
> 1) Increase the descriptive power of the tags. Specific tags make the parts
> of the address absolutely clear, and make it easier to distinguish places
> with similar addresses.

This is one I'm not sure I get, so let's discuss it.

Let's use a real world example (other than the one you use later):

Are you saying it reduces the ambiguity between K Street NW and K
Street SE (in Washington, DC)?

If this would be your example (and I don't know if it is) then I don't
see how it reduces ambiguity, since the name of the street will be
different.

> 2) Provide local mappers with greater specificity and ability to accurately
> tag local conditions. Lumping directionals and street types into addr:street
> obscures local characteristics of addresses.

What kind of local characteristics?

> Since local conditions vary so
> widely across the US, having more tags gives mappers more flexibility to tag
> what they see.

How does it give them more flexibility to tag what they see? Are you
suggesting that this replace (rather than supplement) the "name" tag?

> 3) Remove ambiguity. Look closely at these streets in Hickory, NC and you'll
> see what I mean by ambiguous names and types:
> http://www.openstreetmap.org/?lat=35.75139&lon=-81.35898&zoom=17&layers=M

You keep using the word "ambiguity" but the names appear to be unique
to me- strange, but unique.

> 4) Facilitates supervised imports of address data. I know imports are
> fraught with difficulty (and I'm not explicitly advocating address imports),
> but it is important to note that agencies that manage address data almost
> certainly will have prefix, name, type, suffix broken out.

How does it facilitate import of address data?

And please address the issues #2- users actually using this format.

That's the key feature- will human beings do it?

- Serge

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

[Talk-us] Newly tweaked TIGER road names tiles

[Toby Murray]

As we briefly discussed during the virtual mappy hour last week, I
have managed to wrangle some TIGER data and do some automated
expansion of abbreviated street names on the TIGER road name tiles.
The results can be seen in a new tile layer. You can preview it here:
http://tile.osm.osuosl.org/tiles/tiger2012_roads_expanded/preview.html#17/37.79816/-122.24627

I just added the appropriate URLs for the new layer to the TIGER 2012
page on the wiki so you can use them in JOSM and Potlatch as well:
http://wiki.openstreetmap.org/wiki/TIGER_2012

Since this is a brand new tile layer, nothing is cached in the CDN so
requests might be a little slower than normal at first.

I am fairly certain about the accuracy of the process and the checks I
have performed all came back with good results. But of course TIGER
being such a large and varied data set, there might be an odd edge
case lurking somewhere so it would be great if some people could check
their areas and make sure they don't see anything odd.

The other tweak I made after a suggestion from Ian was to draw the
tiles in two layers. One drawn first with only lines and then another
layer with only names on top of it. This means that road names will
always appear on top of road lines. This avoids roads obscuring names
and improves readability.

Technical details: This was *not* done by doing simple string
matching. I downloaded all of the "Feature Names Relationship" files
which contain separate fields with codes for directional, type and
qualifier prefixes/suffixes. Then I composed the name one element at a
time from these fields. This gave me a mapping from TLID to expanded
street name which I then imported into a new column in the existing
table that is used to render the tiles. Then it was just a simple
matter of telling the mapnik style to look at the new expanded name
column.

Toby

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

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Steven Johnson]

Bill,
That's good info; nice to have some local examples. There are numerous
examples like, "South East Lake Drive" where directionals could be confused
with names. A couple more that come to me off the top of my head...

1) Charlotte, NC has a road called, "The Plaza".
2) Richmond, VA has a road called simply, "Boulevard".

No, you wouldn't want those names broken up either, but you'd want the
ability to unambiguously specify whatever local convention happens to be.

Thanks for weighing in,


-- SEJ
-- twitter: @geomantic
-- skype: sejohnson8

"Common sense is the collection of prejudices acquired by age eighteen." --
Einstein



On Sun, Nov 18, 2012 at 3:55 PM, Bill R. WASHBURN wrote:

> We have to be careful that the availability of this granularity doesn't
> insecure the road names, specifically in cases where part of the road name
> could be confused as a prefix or suffix. Let me throw a few usage cases for
> the metro Atlanta area out to illustrate.
>
> Cobb county uses the quadrant suffix system where everything in the part
> of the county closest to the city of Atlanta gets a SW suffix. Most of the
> time, locals ignore the suffix. Separating the suffix makes sense in this
> context since it is treated as secondary information by locals.
>
> One place where I can see a non-invasive goofing up our local roads is
> North Decatur Road. That road is named after the North Decatur area through
> which it runs, as best I can tell from my local knowledge, therefore making
> "North" part of the name of the road and not a prefix. Locals, when giving
> directions, treat the name as North Decatur, always including, North as
> part of the name. You'll never hear a local send someone to Decatur Road.
> Breaking North away from Decatur does not make sense in this context (and
> the local transit agency confuses locals, me included, by making this
> mistake on the time table charts on their website).
>
> Similarly, The By Way is a road for which separating the prefix, "The,"
> the name, "By," and the road type, "Way," doesn't make grammatical sense
> and the road is not mentioned without the while name. As a local mapper, I
> would not want this name broken up since, in our hyper-local context, it
> does not make sense to do so.
>
> (Compare the second and third cases to East Ponce de Leon Avenue, locally
> shortened to Ponce or Ponce de Leon. The directional prefix and road type
> are treated as secondary, discardable information in local speech.)
> On Nov 18, 2012 3:09 PM, "Steven Johnson"  wrote:
>
>> Richard & Serge,
>>
>> Thanks for the comments. Let me see if I can clarify...
>>
>> The problem: Unlike other (mostly European) countries, there are at least
>> 4 street naming schemes, and 2 property numbering schemes in the US. This
>> makes a set of one-size-fits-all tags for addresses both unwieldy,
>> imprecise, and ambiguous. It forces local mappers to overload the
>> addr:street tag with directional prefixes, suffixes, and street types. It
>> perpetuates ambiguity and lessens the value of the data, as well as
>> constraining mappers from adequately describing local conditions.
>>
>> The solution: splitting out the tags has several advantages:
>> 1) Increase the descriptive power of the tags. Specific tags make the
>> parts of the address absolutely clear, and make it easier to distinguish
>> places with similar addresses.
>>
>> 2) Provide local mappers with greater specificity and ability to
>> accurately tag local conditions. Lumping directionals and street types into
>> addr:street obscures local characteristics of addresses. Since local
>> conditions vary so widely across the US, having more tags gives mappers
>> more flexibility to tag what they see.
>>
>> 3) Remove ambiguity. Look closely at these streets in Hickory, NC and
>> you'll see what I mean by ambiguous names and types:
>> http://www.openstreetmap.org/?lat=35.75139&lon=-81.35898&zoom=17&layers=M
>>
>>
>> 4) Facilitates supervised imports of address data. I know imports are
>> fraught with difficulty (and I'm not explicitly advocating address
>> imports), but it is important to note that agencies that manage address
>> data almost certainly will have prefix, name, type, suffix broken out.
>>
>> Thanks again for the comments. Hopes these comments help make the case
>> for expanded tagging.
>>
>> -- SEJ
>> -- twitter: @geomantic
>> -- skype: sejohnson8
>>
>> "Common sense is the collection of prejudices acquired by age eighteen."
>> -- Einstein
>>
>>
>>
>> On Sun, Nov 18, 2012 at 12:41 PM, Richard Welty 
>> wrote:
>>
>>> i'm sort of on the fence here. perhaps Steven could outline the use
>>> cases for this expanded format;
>>> what becomes possible with it that is not possible or is more difficult
>>> with the current schema?
>>>
>>> richard
>>>
>>>
>>> __**_
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> http://lists.openstreetmap.**org/listinfo/talk-us

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Steven Johnson]

Richard & Serge,

Thanks for the comments. Let me see if I can clarify...

The problem: Unlike other (mostly European) countries, there are at least 4
street naming schemes, and 2 property numbering schemes in the US. This
makes a set of one-size-fits-all tags for addresses both unwieldy,
imprecise, and ambiguous. It forces local mappers to overload the
addr:street tag with directional prefixes, suffixes, and street types. It
perpetuates ambiguity and lessens the value of the data, as well as
constraining mappers from adequately describing local conditions.

The solution: splitting out the tags has several advantages:
1) Increase the descriptive power of the tags. Specific tags make the parts
of the address absolutely clear, and make it easier to distinguish places
with similar addresses.

2) Provide local mappers with greater specificity and ability to accurately
tag local conditions. Lumping directionals and street types into
addr:street obscures local characteristics of addresses. Since local
conditions vary so widely across the US, having more tags gives mappers
more flexibility to tag what they see.

3) Remove ambiguity. Look closely at these streets in Hickory, NC and
you'll see what I mean by ambiguous names and types:
http://www.openstreetmap.org/?lat=35.75139&lon=-81.35898&zoom=17&layers=M

4) Facilitates supervised imports of address data. I know imports are
fraught with difficulty (and I'm not explicitly advocating address
imports), but it is important to note that agencies that manage address
data almost certainly will have prefix, name, type, suffix broken out.

Thanks again for the comments. Hopes these comments help make the case for
expanded tagging.

-- SEJ
-- twitter: @geomantic
-- skype: sejohnson8

"Common sense is the collection of prejudices acquired by age eighteen." --
Einstein



On Sun, Nov 18, 2012 at 12:41 PM, Richard Welty wrote:

> i'm sort of on the fence here. perhaps Steven could outline the use cases
> for this expanded format;
> what becomes possible with it that is not possible or is more difficult
> with the current schema?
>
> 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] Feature proposal: proposed expanded address tagging scheme for US

[Richard Welty]

i'm sort of on the fence here. perhaps Steven could outline the use 
cases for this expanded format;
what becomes possible with it that is not possible or is more difficult 
with the current schema?


richard


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

Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US

[Serge Wroclawski]

Steven,

Thanks for writing this proposal out. I'm one of the people who asked
you to write it up. I think you've given us all a lot to think about.
And while I appreciate the work you've put into this, I don't think
this proposal should become a tagging standard, and I hope that my
explanation rises to the same level as your thoughtful proposal:

I have a few minor points of question, but really, after having looked
at the US roads, I wonder two things about this proposal:

1. Does it add value?

And maybe more importantly:

2. Will individuals contribute data in this new, proposed format?

It's important, when we think about tagging,to consider both issues,
and the second over the first.

1. What is a street name?

To most of us, it's a unique identifier. While in some places, street
types have meaning (eg in Manhattan, streets run east<->west, avenues
north<->south), in most places, the street types themselves do not
contain any additional information about the road.

And even in places where the road type label is meaningful, this
meaning has to be entered, and there's nothing in the proposal to
address this meaning, which makes it "interesting" but not "useful".

The direction tags are somewhat interesting, but I wonder what their
utility is. In a place like Manhattan, the direction tag lets you know
whether you're east or west of 5th Avenue (or Central Park), and in
DC, it lets you know the quadrant you're in. But for this to be useful
to, say a geocoder, it needs additional information which the proposal
does not provide.

So then why separate out the values?

2. Will this proposal be used?

This is the more important of the two questions.

Right now, the biggest source of this information comes from the TIGER
tags. The TIGER tags match this proposal nearly tag for tag, so a
conversion would be very simple.

But the question in my mind is "Will this be used outside TIGER?" - ie
by users (and potentially by an import process).

The OSM tagging community has a history of proscriptive tagging,
whereas if you look at the tags which actually get used and adopted,
most of them are the ones which are in use first, then get documented,
or which get used, and then get put in an editor and used by a larger
community.

What these tags have in common is simplicity- providing information in
the most simple way possible, even if its at the expense of detail.
The other thing they have in common is they provide information that's
not already captured.

This proposal takes one field "name" and split it into six fields.

It would seem that people would be disinclined to fill out this many
fields vs the one field.

So maybe you can give some more of your thinking in your proposal
about why this needs to be there, and if we see any usage outside
TIGER/the US[1].

- Serge

[1] If it's just TIGER, then we already have this data in TIGER fields[2]

[2] Except where people have edited the TIGER fields, which you see
more than you might expect.

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