Re: [Talk-us] Mapping rail trails

[Phil! Gold]

* stevea  [2019-07-11 17:38 -0700]:
> I know it seems "like it just makes sense" to combine Maryland and DC
> relations, but there are rather deliberate reasons to keep these
> separate.  One is state-level, the other is federal-level (is one), but
> the "state at a time for route relations" is a fairly well-established
> method of tossing things into buckets.  We do it with bike routes,
> motorways and more.

However:

The C Trail is contained within the C National Historic Park, which is
owned by the National Park Service, so it's all really at the same
(federal) level.

The "state at a time" pattern, as I have always understood it, exists to
keep vastly distant objects from being linked with each other.  It makes
it much less likely for someone, say, updating I-95 in Florida to get an
editing conflict with someone else who made a change in Massachusetts.
State borders provide convenient locations for the division of overly-lond
relations.

It's also a rule of thumb; I've seen plenty of cases where short distances
in multiple states are aggregated into a single relation.  (e.g. there's
only one relation for US 340, although it spans MD, VA (in two sections),
and WV.)

Since there's only a short section of the C Canal Trail in DC, I don't
really see the harm in putting all of its ways into a single relation.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
Anyone who has never hacked sendmail.cf has no soul.  Anyone who has
hacked it twice has no brain.
   -- Peter da Silva
 --- --

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

Re: [Talk-us] Mapping rail trails

[Phil! Gold]

* Richard Fairhurst  [2019-07-11 01:56 -0700]:
> It would be good to have a distinct C Canal Trail relation over and
> above the USBRS 50 relation, for example.

You mean aside from these?

  https://www.openstreetmap.org/relation/1392951
  https://www.openstreetmap.org/relation/9773990

I suppose it is a little silly to have a separate DC portion; I could just
go combine them into a single relation.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
The Old Man and the Sea LITE(tm)
by Ernest Hemingway

An old man goes fishing, but doesn't have much luck.
 --- --

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

Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))

[Phil! Gold]

* Phil! Gold  [2019-03-08 17:44 -0500]:
>   https://gitlab.com/asciiphil/osm-shields

Oops, that's the master branch, which doesn't have the changes.  You need
to look at the svg branch:

  https://gitlab.com/asciiphil/osm-shields/traa/svg
  
-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
#if _FP_W_TYPE_SIZE < 32
#error "Here's a nickle kid.  Go buy yourself a real computer."
#endif
   -- linux/arch/sparc64/double.h
 --- --

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

Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))

[Phil! Gold]

* Kevin Kenny  [2019-03-08 14:25 -0500]:
> On Fri, Mar 8, 2019 at 11:37 AM Martijn van Exel  wrote:
> >
> > I agree that a local US OSM map with a *subtly* adapted rendering would be 
> > fantastic. Phil Gold did some interesting work years ago on rendering US 
> > style highway shields taking into account (sometimes crazy) route 
> > concurrency 
> > (http://elrond.aperiodic.net/shields/?zoom=13=39.75926=-86.02786=B
> >  - note that this is based on years-old data and probably pre-carto-switch 
> > stylesheet). Lars Ahlzen created the beautiful TopOSM which is a lot more 
> > divergent from the main map style, but another great example of initiatives 
> > around custom map rendering coming out of the US community.
> 
> I've borrowed ideas (and some limited amount of code) from both of
> them in doing my experimental rendering
[snip]
> The chief roadblocks to scaleability are that the graphics are
> generated in what amounts to a batch process, taking several minutes,
[snip]
> Then there's the issue that the graphics for individual shields are
> being stored in PNG, which is rendered in a batch process that takes
> typically several minutes (so could not cope with minutely updates).

I started work last year on a better system that generates SVGs on the fly
from OSM data, so it doesn't need the pregeneration step.  I got bogged
down with other things before I quite finished, but it's mostly there.
(There are just a few Canadian routes left to convert; I was having
difficulty finding official specs for their signs.)

I don't think this is really documented yet, but I now support four
different sign styles, passed as the `style` parameter to the Python
rendering functions:

 * "generic" uses a standard, generic style for every US state and county,
   disregarding their individual styles.
 * "guide" matches the styles used on highway guide signs.  This is now
   the default, since it seems most fitting to map rendering.
 * "sign" looks like the roadside reassurance markers.
 * "cutout" is a modification of the "sign" style to remove dark
   background areas.  This used to be the default with my old system.

Anyway, the code is here:

  https://gitlab.com/asciiphil/osm-shields

Hopefully at some point I'll find time to finish up my changes.  (And,
ideally, merge in all of the extra shields you and Minh have put
together.)

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
What computers do Daleks use?  X-TERMINALS, X-TERMINALS!
 --- --

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

Re: [Talk-us] Representing census-designated places (CDP), Census County Division (CCD), etc

[Phil! Gold]

* Nelson A. de Oliveira  [2016-04-28 16:24 -0300]:
> Do you represent [CDPs] (and maybe other statistical boundaries) in OSM?
> If yes, what are you using? (boundary=?, border_type=?, etc)

As people have indicated, practices vary.

I live in a region where very few named population centers have legal
administrative boundaries[0], so a) we have a lot of CDPs, and b) the CDPs
are useful approximations of the geographic extents of places that people
refer to by name on a day-to-day basis.

What I often do (because I've seen others do it) is take the CDPs that
were imported from the US Census's TIGER dataset and change them from
boundary=administrative to boundary=census.  (I also drop the
admin_level=8 tag.)  Most of these places also have a place=* node, which
I don't usually merge with the CDP, mostly for fuzzy personal reasons
like, "The CDPs are useful enough to keep around but I don't always feel
like they're right *enough* to supplant a place node at the rough
geographic center of the place."


[0] In Maryland, the counties tend to perform a lot of administrative
functions like road maintenance, fire and police services, and school
operations.  Consequently, there's not a strong need for most
communities to incorporate so most don't.  Boundaries between adjacent
populated places are very fuzzy and driven a lot by what the people
who live there happen to say about themselves.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
There's a frood who really knows where his towel is.
 --- --

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

Re: [Talk-us] Strategy for Naming Parts of a Large Park

[Phil! Gold]

* Elliott Plack  [2016-03-01 14:49 +]:
> [Patapsco Valley State Park] consists of several nine or so areas (2)
> spread out over 30 miles of the Patapsco River valley. Some of the parts
> are contiguous, others not.

The sub-areas also do not have (or do not always have) well-defined
boundaries.  The park itself is well-defined (and already has a
multipolygon border), but most of the sub-areas would either be nodes or
areas whose edges aren't really authoritative.

At the moment, there's a single multipolygon for the entire state park,
tagged leisure=park and boundary=protected_area, protect_class=5.  The
individual areas are generally nodes tagged leisure=park with names like
"Patapsco Valley State Park - McKeldin Area".  The whole park-in-a-park
thing feels a little off to me, but it does get the names rendered on the
default map.  :-/

(Elliott knows all this, but I thought it might be useful information for
the discussion.)

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
Join the non sequitur society. We may not make sense but we do like pizza.
 --- --

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

Re: [Talk-us] Best practices for coastline to Inland Bay / River transition

[Phil! Gold]

* Elliott Plack  [2016-01-07 20:12 +]:
> What are the current accept[ed] best practices for determining where to "cut
> off" the coastline and to begin a river or bay type feature? The wiki seems
> to be in disagreement about this, and I've read chatter about switching to
> ocean polygons.

I'm not sure I've seen a best practice, really, but I have in the past
closed off rivers at their mouths and then tagged their (multi)polygons
waterway=riverbank, tidal=yes.  (Sometimes it can be difficult to tell
where a river stops being tidal, but at least the Potomac doesn't have
that problem.)

My reasoning is essentially along the same lines as what to do when one
river flows into another: at some point the smaller river ends and you
could do worse than to draw a line across the mouth of that river and say,
"Everything on this side is River A and everything on the other side is
River B".  Likewise, at some point, the ocean stops being the ocean (or
the Chesapeake Bay stops being the Chesapeake Bay), so why not at the
mouth of the river?

Bays are a little more problematic, as there's not always as obvious a
mouth as for a river, plus features like bays and coves can coexist with
other features like rivers.[0]  I usually leave bays as point features
unless there's a really obvious delineation between them and everything
else.

I actually went through the work of cutting the Potomac off from the
coastline of the Chesapeake Bay and turning it into riverbank
multipolygons a few years ago, but JOSM crashed and lost my work before I
was able to upload it and I felt too depressed to go back and redo
everything.  I believe I have since gone back and put in *some* riverbank
multipolygons at the upstream end of the tidal region of the river.

[0] I know according to some points of view, the entire Chesapeake Bay is
just the lowest part of the Susquehanna River, but I'm pretty
comfortable leaving the Bay as coastline.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
"I don't trust dreams."
"They said they weren't dreams."
"So?  Dreams lie."
   -- "The Kindly Ones", Neil Gaiman
 --- --

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

Re: [OSM-talk] stop deleting abandoned railroads

[Phil! Gold]

* Martin Koppenhoefer dieterdre...@gmail.com [2015-08-21 09:22 +0200]:
 railway=dismantled means there is no railway currently but there are clear 
 traces / remains of a railway (because if there weren't we would not put it 
 in Osm).

Just for clarity:

railway=abandoned (per the wiki and my understanding of things) is for
when there remain traces of a railway whose rails are no longer present.
railway=dismantled (and its synonym, railway=razed) was introduced to
cover the case where people wanted to tag the path of a former railway
where no traces of the railway remain (e.g. because the area was
completely leveled to may way for a subdivision or mall).  (Reasons for
using railway=dismantled usually amount to, The railway=abandoned traces
on either side of the leveled area make the former presence of a railway a
ground truth (because you wouldn't just have a gap in a railway) so the
railway=dismantled way bridges that gap in the OSM database.)

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
Brillineggiava, ed i tovoli slati
girlavano ghimbanti nella vaba;
i borogovi eran tutti mimanti
e la moma radeva fuorigraba.
   -- Lewis Carroll, Jabberwocky
 --- --

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

Re: [Talk-us] cycle.travel US bike routing, and unreviewed rural TIGER

[Phil! Gold]

* Jack Burke burke...@gmail.com [2015-06-22 08:32 -0400]:
 On June 22, 2015 2:46:36 AM EDT, Bryce Nesbitt bry...@obviously.com wrote:
  tiger:reviewed=no
 
 Most of the well reviewed Tiger I see still has this tag.
 People don't know to delete it.

 Usually I change it to =yes instead of just deleting it. The main reason
 is I frequently use ITOworld maps to review the county I live in to find
 unreviewed roads, and I like the color pattern better that way.

Hm.  Maybe I'll start doing that.  I also use tiger:reviewed=position to
signify that I've armchair-mapped the way to align with aerial imagery but
haven't yet been out to verify the road name.  (Details about my use of
this tag are in this diary entry:

  http://www.openstreetmap.org/user/asciiphil/diary/16247

)

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
NOTICE:
Anyone seen smoking will be assumed to be on fire and will
be summarily put out.
 --- --

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

Re: [Talk-us] Importing parks and schools for Anne Arundel County MD

[Phil! Gold]

* Gregory Arenius greg...@arenius.com [2014-05-30 00:52 -0700]:
   The only other thing that stuck out to me about the data was the B  A
 trail.  You have a polygon for the trail which is awesome but I would also
 add in a properly tagged linear way.  It will make it possible for routers
 to use it as well as rendering properly.

The trail is already in OSM as a linear feature.

I think the import process should be semi-manual, though, as the landuse
polygons need to be integrated with existing OSM data.  (e.g. there are a
number of residential areas abutting the BA Trail, so the edges of those
should be merged, rather than left overlapping each other.)

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

Re: [Talk-us] State ref tags on ways

[Phil! Gold]

* Elliott Plack elliott.pl...@gmail.com [2014-03-28 02:53 -0400]:
 Interesting note about this in Maryland. My friend Mike showed me that some
 mappers have been using the *county* route numbers on some county roads in
 Maryland.

Since Maryland counties don't sign their route numbers[0], they're using
unsigned_ref=, not ref= in their way and route relation tagging, right?


[0] In any county I'm directly familiar with, at least; I don't go to
southern Maryland much, and I don't usually venture far outside the US
50 corridor on the Eastern Shore.

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

Re: [Talk-us] NAIP Imagery Servers -- Need Assistance Setting Up in JOSM

[Phil! Gold]

* Kam, Kristen -(p) krist...@telenav.com [2014-03-24 17:26 +]:
 The other week, I came across the directory of USDA's WMS NAIP Image
 Services (by state). QGIS renders the images with no problem, but it
 appears to fail in JOSM.

If it helps, OSM-US hosts a tile proxy for the USGS-hosted NAIP imagery.
It's documented on the US Imagery page:

  
http://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/United_States/Servers/Imagery

The best layer to use is probably the USGS Large Scale Imagery, which uses
NAIP at low resolutions and switches to the USGS High Resolution
Orthophotography at higher resolutions.  The JOSM configuration for it is:

  
tms:http://{switch:a,b,c}.tile.openstreetmap.us/usgs_large_scale/{zoom}/{x}/{y}.jpg

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

Re: [OSM-talk] [Talk-us] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

[Phil! Gold]

* Florian Lohoff f...@zz.de [2014-03-16 10:38 +0100]:
 On Sat, Mar 15, 2014 at 11:03:41AM -0400, Phil! Gold wrote:
  I suspect that Map Maker would attract more people that might
  otherwise have ended up contributing to OSM, which would hurt
  community growth and benefit Google at the expense of all the other
  OSM data consumers.
 
 But this is technically impossible. Either you take OSM and the flow of
 changes of contributers for a certain area, or you take some snapshot
 and let your community edit it by cutting off the OSM stream.

Google appears to do both, probably because they've gotten really good at
data conflation.  They already pull data from multiple datasets, including
proprietary data like Telenav's, public domain data from governments and
such, and restricted use data from local governments, and then they
integrate GMM contributions on top of that amalgamation.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
A funny symbol that I can't read has just been input.
Continue, and I'll forget that it ever happened.
   -- TeX error message
 --- --

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

Re: [OSM-talk] [Talk-us] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

[Phil! Gold]

* Alex Barth a...@mapbox.com [2014-03-13 10:26 -0400]:
 http://www.openstreetmap.org/user/lxbarth/diary/21221

This is really similar to the discussions that periodically happen in the
open source software community over whether share-alike licenses like the
GPL or open-use licenses like the 3-clause BSD license are better.

I usually end up on the side of share-alike for reasons best summed up by
a friend of mine who once said, The GPL restricts your freedom to be
evil.  The BSD license doesn't.

I think that if your goal is to have as many people as possible using your
data, you're best off choosing open-use or public domain licensing.
(Richard Weait and I chose to go with CC0 and PDDL for the data in the
shield rendering so as to allow for as much variance of reuse as
possible.  Similarly, it makes sense for US federal government data,
because their mandate is to be as useful to US citizens as possible.)

If, however, you want to foster a community around a larger scale project,
I think share-alike is a better path to take.  If OSM switched to public
domain licensing today, there would almost certainly be more people using
and benefiting from today's OSM data.  Google in particular would probably
make OSM data part of its data; they already merge numerous public domain
datasets into their proprietary dataset.  That would make Google the
better choice for a lot of people than plain OSM data, and you can even
edit Google's data through their Map Maker program.  From there, I suspect
that Map Maker would attract more people that might otherwise have ended
up contributing to OSM, which would hurt community growth and benefit
Google at the expense of all the other OSM data consumers.

In my opinion, the single biggest thing that makes OSM valuable is the
community of people contributing to it, and the license on the data needs
to reinforce that community, not allow proprietary data uses to splinter
it.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
lately my mania has been mega-lo-mein-ia, which is to say i believe the
plate of noodles is larger than i am.
   -- elysse
 --- --

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

Re: [Talk-us] State ref tags on ways: Use of unique ISO/ANSI/USPS 2-letter state codes in RELATIONS as well as WAYS?

[Phil! Gold]

* Toby Murray toby.mur...@gmail.com [2014-03-12 00:33 -0500]:
 I went and verified some things about bannered routes. It looks like the
 current shield rendering looks for network=X:Y:Modifier. So for example the
 US 50 truck route in Cincinnati is network=US:US:Truck and ref=50.
[snip]
 Looking around it looks like the other convention that has some decent use
 in the database (but is not currently supported by any renderings) is to
 add a modifier=Truck/Business/Spur/etc tag.

I believe the wiki recommends that bannered routes get a modifier tag in
addition to having the modifier in the network tag, so US 50 Truck is
network=US:US:Truck, ref=50, modifier=Truck.  The idea is that data
consumers can get the parent route network by subtracting modifier from
network.  (But data consumers that don't care about parent route networks,
like the shield rendering, don't have to know about the modifier tag.)

I don't know of any data consumers that make use of the modifier tag
currently, but there weren't many consumers making use of route relations
in general before the shield rendering.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
The truth is not free.  It's that simple.  If you change the truth, it is
no longer true - so the truth is not free!
   -- Jules Bean about freeness of documentation
 --- --

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

Re: [Talk-us] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

[Phil! Gold]

* Alex Barth a...@mapbox.com [2014-03-13 10:26 -0400]:
 http://www.openstreetmap.org/user/lxbarth/diary/21221

This is really similar to the discussions that periodically happen in the
open source software community over whether share-alike licenses like the
GPL or open-use licenses like the 3-clause BSD license are better.

I usually end up on the side of share-alike for reasons best summed up by
a friend of mine who once said, The GPL restricts your freedom to be
evil.  The BSD license doesn't.

I think that if your goal is to have as many people as possible using your
data, you're best off choosing open-use or public domain licensing.
(Richard Weait and I chose to go with CC0 and PDDL for the data in the
shield rendering so as to allow for as much variance of reuse as
possible.  Similarly, it makes sense for US federal government data,
because their mandate is to be as useful to US citizens as possible.)

If, however, you want to foster a community around a larger scale project,
I think share-alike is a better path to take.  If OSM switched to public
domain licensing today, there would almost certainly be more people using
and benefiting from today's OSM data.  Google in particular would probably
make OSM data part of its data; they already merge numerous public domain
datasets into their proprietary dataset.  That would make Google the
better choice for a lot of people than plain OSM data, and you can even
edit Google's data through their Map Maker program.  From there, I suspect
that Map Maker would attract more people that might otherwise have ended
up contributing to OSM, which would hurt community growth and benefit
Google at the expense of all the other OSM data consumers.

In my opinion, the single biggest thing that makes OSM valuable is the
community of people contributing to it, and the license on the data needs
to reinforce that community, not allow proprietary data uses to splinter
it.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
lately my mania has been mega-lo-mein-ia, which is to say i believe the
plate of noodles is larger than i am.
   -- elysse
 --- --

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

Re: [OSM-talk] Admin borders/separate database

[Phil! Gold]

* Paul Johnson ba...@ursamundi.org [2013-11-05 09:18 -0600]:
 On Tue, Nov 5, 2013 at 8:05 AM, Janko Mihelić jan...@gmail.com wrote:
  The problem is, some admin borders are supposed to be glued to roads or
  rivers, and they change when the flow of a road or river changes. How do
  you deal with that?
 
 Well, historically, the border doesn't move.

It depends.  In some cases, it doesn't move.  In other cases, if the
course of the river changes gradually by natural means (i.e. not someone
digging a new channel for it), the boundary is considered to move with it.

There's also the consideration that people might improve OSM's river or
road data over time.  If a boundary is glued to a road, but that road is
poorly-aligned in OSM, the user who improves its accuracy should be
updating both the road and the boundary.

Personally, I think that OSM's ball-of-mud approach to data is one of its
strengths and separating out its data into layers would be more of a
negative than dealing with all of the issues that come from mingling
administrative boundaries with everything else.

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

Re: [Talk-us] Question about incorrect data for an administrative area

[Phil! Gold]

* Jay Boyer bo...@snhdmail.org [2013-10-10 13:34 -0700]:
 Enterprise is an unincorporated town.  But Enterprise is actually part of Las 
 Vegas and all of the addresses within Enterprise are Las Vegas addresses.
 
 Enterprise is this area:  http://www.openstreetmap.org/browse/relation/170132

There are a couple of things going on here.

First, if Enterprise does not have its own government, it probably
shouldn't be boundary=administrative.  I've seen people use things like
boundary=census for unincorporated towns where the town boundary is a
CDP from the US Census data import.

Second, place=locality is for locations that are not associated with a
population center.  Based on my understanding of the tags, for a place
that is considered to be within a place=city, you should use either
place=suburb (for major or notable city divisions, which it sounds like
Enterprise is) or place=neighbourhood.  Nominatim will order either of
those tags hierarchically with the city-tagged place, so address lookups
will work for both Street Name, Enterprise, NV and Street Name, Las
Vegas, NV.

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

Re: [Talk-us] Current status with highway shields?

[Phil! Gold]

* Evin Fairchild evindf...@gmail.com [2013-10-09 19:54 -0700]:
 I emailed Phil Gold (creator of the awesome shield rendering) about this
 almost a month ago, but he never responded so this hasn't been fixed.

Er, sorry about that.  I've been extremely busy for about the past two
months, and probably won't really have time to dedicate to the shields for
at least another month or two.

I did start experimenting with carto a while back, so when I have time for
the shields again, that'll be a high priority item since, based on my
experience so far, I don't think it'll be too hard to work in to the new
stylesheet.

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

Re: [Talk-us] Shields are up!

[Phil! Gold]

* Toby Murray toby.mur...@gmail.com [2013-07-28 22:38 -0500]:
 http://tile.openstreetmap.us/osmus_shields/preview.html

Awesome!  Thanks for all your work in making this happen!

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

Re: [Talk-us] Shields are up!

[Phil! Gold]

* Richard Welty rwe...@averillpark.net [2013-07-29 08:17 -0400]:
 one thing to consider in NY, though - not all counties use the
 yellow-on-blue pentagonal County Route signs. right now it's
 automagically using that style shield for all county routes.
 should we deal with this or let it go?

I'd prefer to deal with it.  I'd like the shields to match actual road
signs as much as possible.

If you can get me a list of what New York counties use which sign styles,
I'll work on getting the rendering to match them.  For what it's worth,
Minh Nguyen has been working with other Ohio mappers to both get Ohio's
county routes into OSM and to document the signage (and the tagging
they're using) at http://wiki.osm.org/wiki/Ohio/Route_relations/Networks ;
I would not at all object if people put together similar references for
other states with diverse county sign styles.  :)

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

Re: [Talk-us] Shields are up!

[Phil! Gold]

* Michal Migurski m...@teczno.com [2013-07-29 00:40 -0700]:
 I wonder if this would be helpful: I've been generating weekly generalized 
 datasets of route relations.
 
   http://openstreetmap.us/~migurski/streets-and-routes/
 
 The tiles take a little while to render, so I wonder whether using an 
 intermediate data set would cut some corners while reducing repeat labels?

One of my goals with this project was to make a rendering that works off a
minutely-updated rendering database.  It could probably be adapted to work
off postprocessed datasets like your generalized route relations (though I
don't know (because I haven't looked at your data) whether shield clusters
would be easily derivable), but I think that having a minutely-driven
rendering is really beneficial to mappers working on data the rendering
highlights.

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

Re: [Talk-us] Shield rendering and detours; tagging nicknames?

[Phil! Gold]

* Paul Johnson ba...@ursamundi.org [2013-07-13 18:52 -0500]:
 OK, wonder if we can get orange detour banners for routes as well?  Example
 relations can be found in the downtown Tulsa area, which has an interstate
 (244), two US routes (64, 75) and an Oklahoma state highway (51) detoured
 through the end of next year.

I'll see about adding stuff under US:I:Detour, US:US:Detour, and, I
guess, US:OK:Detour.

 I've also finally gotten around to adding
 relations for the LL Tisdale Parkway (
 http://www.alpsroads.net/roads/ok/cool_j/) and the Gilcrease Expressway (
 http://www.aaroads.com/shields/show.php?image=OK19720071) to test out city
 route shields.

I'll add them to the list of routes needing shields.  What network are
you using for those?

 Also, what would be an appropriate tag for a completely informal name for
 something that is getting uptake by way of traffic reports?  Tulsa's Inner
 Dispersal Loop has been called the Inner Detour Loop by some reporters.

Based on http://wiki.openstreetmap.org/wiki/Names , I'd say loc_name=.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
If the beautiful princess that you capture says, I'll never marry you!
Never, do you hear me, NEVER!!! say, Oh well, and kill her.
   -- Evil Overlord's Handbook, entry 53
 --- --

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

Re: [Talk-us] Releasing my data into Public Domain

[Phil! Gold]

* Elliott Plack elliott.pl...@gmail.com [2013-07-18 14:25 -0400]:
 Question to you: On our website, we are uncertain as how to say, The data
 is public domain. Can you all provide examples of other sites that provide
 data that has been imported into OSM?

I don't know of any large sites using it, but this seems to be exactly the
sort of thing that the Open Data Commons' Public Domain Dedication and
License was intended for:

  http://opendatacommons.org/licenses/pddl/

The PDDL extends CC0 to datasets in the same way that the ODbL extends
CC-BY-SA.

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

Re: [Talk-us] Update on highway shield rendering

[Phil! Gold]

* James Mast rickmastfa...@hotmail.com [2013-07-15 00:36 -0400]:
 Man, there are TONS of bannered routes in GA.  It might take forever to
 find out all of them, even with using GA's own maps to find them.

Well, I wrote a tool[0] that looks at the rendering database and gives me
a list of route relations without shields.  In the worst case, someone
would add a new bannered route and it would sit unrendered until I looked
at the missing shields page and saw I needed to add it.

[0] 
http://bazaar.launchpad.net/~asciiphil/osm-shields/trunk/view/head:/show_missing.py

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

Re: [Talk-us] Update on highway shield rendering

[Phil! Gold]

* James Mast rickmastfa...@hotmail.com [2013-07-13 20:46 -0400]:
 In GA, it seems you're not supporting the US:GA:Connector network.

I do support US:GA:Connector, but I didn't have an entry for Connector
40.  (I do now.  :) ) I an effort to reduce the amount of time needed
for shield generation, I tend to specify only the specific bannered
routes I know about, either from personal experience, Wikipedia, or
looking at OSM data.  I'm pondering a change to the bannering code
that would handle most cases more dynamically (but not for Georgia,
since they don't actually use banners for their bennered routes...).

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
The ring needs another token.
   -- BOFH excuse #129
 --- --

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

Re: [Talk-us] Update on highway shield rendering

[Phil! Gold]

* James Mast rickmastfa...@hotmail.com [2013-07-11 14:02 -0400]:
 I know that there is a US 1-9 in NJ, but this error is showing up in NC. ;)

Oh, wow.  That *is* a bug.

I've got to figure out how to handle it, but here's what's going on:

Those ways (take http://www.openstreetmap.org/browse/way/11177 as an
example) are members of three relations: NC Strategic Highway Corridor 34,
US 1, and US 1 Bypass.  (Like the other case that came up recently, I
question whether it's *really* both US 1 and US 1 Bypass.)  US 1 Bypass is
tagged as network=US:US, ref=1, modifier=Bypass, so the rendering treats
it as a duplicate of US 1.  The consolidation algorithm I wrote for US 1-9
is a little naive; it matches against US 1 and US 9 and if it gets two
matches, it substitutes in US 1-9.  The duplicate US 1 relations give it
two matches, so it does the substitution.

I'll have to think a bit about how I want to address this bug.

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

Re: [Talk-us] Update on highway shield rendering

[Phil! Gold]

* Phil! Gold phi...@pobox.com [2013-07-11 15:32 -0400]:
 * James Mast rickmastfa...@hotmail.com [2013-07-11 14:02 -0400]:
  I know that there is a US 1-9 in NJ, but this error is showing up in NC. 
  ;)
 
 Oh, wow.  That *is* a bug.

And now it's fixed.  :)  The replacement code will only kick in if both
parts of the precondition are met.

This does raise a thought for me.  I'm going to see if I can convince my
code to spit out a shield for every relation, even if two of them are
duplicates of each other.  That will better highlight cases like this
where two overlapping routes have the same apparent definitions.

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

Re: [Talk-us] Future Interstate Relations

[Phil! Gold]

* James Mast rickmastfa...@hotmail.com [2013-07-09 01:40 -0400]:
 So, does anybody else have any more comments on how we should deal with
 tagging these Future Interstates?

Given that previous list consensus was for tagging of the form:

network=US:I:Future
ref=number
modifier=Future

and that only one person offered a variant opinion this time around, I'd
recommend tagging as above.

Also, from your earlier emails, I have future interstates 26, 73, 74, and
840.  Are there any others?

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

Re: [Talk-us] Future Interstate Relations

[Phil! Gold]

* James Mast rickmastfa...@hotmail.com [2013-07-10 08:59 -0400]:
 There is one other.  I mentioned it in my e-mail from yesterday
 (07-09-13).  That is I-295 in Fayetteville.

Okay, I've got that one in my rendering now, too.

 And to be honest, I thought some people wanted the :Future part
 dropped out and just put in the modifier area.

This time around, one person suggested that.  (In previous discussions
there was a second opinion along those lines, but he's not on this list at
the moment.)  In the past, everyone else who's voiced an opinion has gone
for the US:I:Future style of tagging, and no one else even chimed in this
time.

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

Re: [Talk-us] Update on highway shield rendering

[Phil! Gold]

* James Mast rickmastfa...@hotmail.com [2013-07-10 09:22 -0400]:
 I could fix the PA Turnpike relation with the US:PA:Turnpike network
 tag in a moment.  Would that work instead of just fixing the name tags
 for both directions?

That wouldn't affect my rendering as it currently stands.  The rendering,
right now, will only make a shields for a relation with the exact name
Pennsylvania Turnpike.

 I only split it up because it was getting close to 1,000 ways and
 thought it would be easier to edit in the future having two smaller
 relations, one for each direction. -James

Yeah, the same reason we split national routes on a state-by-state basis.
The practice of putting stuff like I-95 (VA) in the name tag on those
doesn't interfere with my rendering because those relations have ref tags,
even though that's not really the name of the route.

What we really need is a tag like name:relation that the editing tools can
use for labeling things in their UIs when we want something more
descriptive than precise use of the name tag can give us.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
  Well, what IS the song, then? said Alice, who was by this time
completely bewildered.
  I was coming to that, the Knight said.  The song really IS 'A-SITTING
ON A GATE': and the tune's my own invention.
   -- _Through the Looking-Glass_, Lewis Carroll

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

Re: [Talk-us] Update on highway shield rendering

[Phil! Gold]

* Richard Welty rwe...@averillpark.net [2013-07-10 09:58 -0400]:
 an NJTP shield is probably appropriate. the turnpike is _not_ precisely
 I-95.

I think I was unclear in my question.  I have a New Jersey Turnpike shield
that I want to use.  My question is: should the route relation for the New
Jersey Turnpike be tagged ref=NJTP or should it have no ref tag at all?

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

Re: [Talk-us] Future Interstate Relations

[Phil! Gold]

* Paul Johnson ba...@ursamundi.org [2013-07-10 10:16 -0500]:
 I don't think we hit a consensus, did we?  Seems like we were talking
 about whether having a modifier tag or not, and if not, including the
 banner in the network.

As I documented at
http://gis.19327.n5.nabble.com/Highway-Shield-Rendering-tt5612357.html#a5640994
, I think there's definitely a consensus around putting the banner in the
network.

 I don't recall anybody proposing doing both (which seems redundant on
 multiple levels).

I don't recall a specific discussion about whether to use the modifier tag
with the banner already in the network tag, but the wiki (at
http://wiki.openstreetmap.org/wiki/United_States_roads_tagging#Tagging_with_relations
) implies that the modifier tag should duplicate the banner present
elsewhere, and I've seen the practice in OSM data (from at least NE2, but
I'm reasonably sure I've seen other people tagging in this way, too).

Separately from the practice that I've seen, I think that having the
modifer separate as well as in the network tag allows data consumers to
easily work back to the root network while still preserving the
uniqueness constraints for consumers that only process the network and ref
tags.

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

Re: [Talk-us] Update on highway shield rendering

[Phil! Gold]

* James Mast rickmastfa...@hotmail.com [2013-07-10 10:44 -0400]:
 http://www.openstreetmap.org/browse/way/172380289

There are some interesting things going on here.

Is this road really part of both US 21 and US 21 Bypass?  That seems weird
to me, but if someone says that's how the road's signed I'll believe it
(see: US 1-9 signage...).

Also, the map really ought to show bypass shields for the roads that are
part of US 21 Bypass.[0]  My rendering is not doing so because US 21
Bypass has network=US:US (not network=US:US:Bypass), so it's treated as
mainline US 21.


[0] Like US 341 Bypass here:
http://elrond.aperiodic.net/shields/?lat=32.4739lon=-83.7315zoom=14

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

Re: [Talk-us] Update on highway shield rendering

[Phil! Gold]

* Paul Johnson ba...@ursamundi.org [2013-07-10 10:28 -0500]:
 On Wed, Jul 10, 2013 at 2:18 AM, James Mast rickmastfa...@hotmail.comwrote:
  Also, do you guys think for the PA Turnpike XXX routes, that the
  network tag for them should be US:PA:Turnpike
 
 That's how I've been handling the Oklahoma situation: US:OK:Turnpike.

Yep:

http://elrond.aperiodic.net/shields/?lat=34.55064lon=-96.94071zoom=13

:)

I only see two US:OK:Turnpike routes in the database at the moment, and
the Cherokee Turnpike suffers from the same issue as the PA Turnpike has
currently; my rendering doesn't understand name=Cherokee Turnpike
(eastbound).  I'm still not sure what the best way to handle that is.

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

Re: [Talk-us] Tagging a super-two highway (trunk or motorway?)

[Phil! Gold]

* Toby Murray toby.mur...@gmail.com [2013-06-30 03:39 -0500]:
 So then we come back to the question of what exactly is trunk if it isn't
 used for these kinds of roads?

I've thought of them as something like really major but not
Interstate-grade roads.  Primary roads are main roads, obviously, but
trunks have better throughput.  I mentioned MD 90 earlier; in the same
region is the easternmost part of US 50 which is a divided highway
with at-grade intersections and periodic (but not frequent) traffic
lights.  It's designed to get a lot of people to and from Ocean City,
MD in an efficient way.  I think it definitely fits as a trunk.

I think most of the things I would consider trunk are divided, but I
have seen undivided roads that others have tagged trunk and thought,
Yeah, that makes sense there.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
#define FALSE   0   /* This is the naked Truth */
#define TRUE1   /* and this is the Light */
   -- mailto.c
 --- --

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

Re: [Talk-us] Future Interstate Relations

[Phil! Gold]

* James Mast rickmastfa...@hotmail.com [2013-06-26 22:34 -0400]:
 I thought the modifier would be the type of Business route?
 Remember, we do have Business Spurs and Business Loops for
 Interstate highways.  Sometimes both types in the same city.

Every Business Interstate is signed as either a spur or loop, so I
would consider the full modifier to be either Business Spur or
Business Loop.

For lack of a better approach, I set up the shield rendering to
process them with network values of US:I:Business:Spur and
US:I:Business:Loop.  I guess the value of the modifier tag could be
either Business:Spur or Business Spur.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
$a='X'; print map \$a='$a'; $_, q($_), q(print map \$a='$a';$_, q($_))

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

Re: [Talk-us] Future Interstate Relations

[Phil! Gold]

* Paul Johnson ba...@ursamundi.org [2013-06-26 23:25 -0500]:
 Looks like the spur extends the loop, I'm not sure I'd differentiate
 them in modifier, but might in the description.

They're signed differently, so I think that makes them distinct enough
to be treated differently.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
Photons have neither morality nor visas.
   -- David Farber
 --- --

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

[Talk-us] Route Relation Tagging, again (was Re: ref tags)

[Phil! Gold]

* Paul Johnson ba...@ursamundi.org [2013-06-24 09:11 -0500]:
 network=US:I
 modifier=Future

* James Mast rickmastfa...@hotmail.com [2013-06-25 00:15 -0400]:
 Now, I'm going to initially use the following to tag the Future
 segments inside of relations: network=US:I:Future However, somebody else
 suggested this: network=US:I modifier=Future Which do you guys think
 would be the better way to go?

There's been discussion about how to tag the relations for bannered routes
in the past.  My understanding of the list consensus, as I summarize in
this previous email:

  http://gis.19327.n5.nabble.com/Highway-Shield-Rendering-tp5612357p5640994.html

is that Future Interstate 26 should be tagged as follows:

network=US:I:Future
ref=26
modifier=Future

However, in a Google Hangout last week, Paul indicated a desire to reopen
the discussion on tagging bannered routes, so here we go:

There are basically three options for tagging bannered routes.  I'll use
Future I-26 as an example here, but the principle applies equally to any
other routes.

Option A (network-classification-per-banner):

network=US:I:Future
ref=26
modifier=Future

Option B (banner-in-ref):

network=US:I
ref=26 Future
modifier=Future

Option C (banner-in-modifier):

network=US:I
ref=26
modifier=Future

In my opinion, either option A or option B should be used.  Because a
veriety of people with a variety of OSM experience edit OSM data, I think
it's important to consider how damaged or incomplete data will be treated
by data consumers.

In any of the above cases, a data consumer that only sees or understands
the ref= tag (e.g. something that was written to handle ways and is now
looking at a relation) will not get a complete picture, but also won't get
a wrong impression (thinking that I-26 is US 26 or something similar).
Furthermore, the network/ref tagging has been pretty well established on
the wiki and in general usage for some time now.

If a data consumer only sees or understands the network and ref tags, both
options A and B will give it a complete picture of the route, but option C
will be incorrectly interpreted as the main I-26.  I think that's a pretty
strong argument against option C.  In programming or database design, one
strives to eliminate all duplication, but in a project like OSM I think a
little duplication of data serves as useful redundancy.

Note that if the modifier tag is present, both options A and B can be
processed to remove the redundant information if that's desired.

I think the choice between options A and B is more of an aesthetic one.
What matters is that there is a consensus on what the tagging is.  I think
in previous discussions more people were tipped toward option A because it
makes the decision of when to use a different network easy, because
network essentially means different road sign.  Option B has a little
more grey area, since there were people (well, mostly NE2) saying things
like alternate and business Interstates are clearly not part of the
Interstate Highway System, but alternate and business US Highways are
clearly part of the US Highway System (paraphrase from [1] and [2]).

  [1]: 
http://gis.19327.n5.nabble.com/Highway-Shield-Rendering-tp5612357p5636639.html
  [2]: 
http://gis.19327.n5.nabble.com/Use-of-ref-tag-on-state-highways-tp5285587p5285594.html

As I said before, my understanding of the list consensus in previous
discussions is for option A and that's what my renderer understands (see
[3]).  If you have an opinion on what we should be using (whether it's one
of options A, B, or C above or some other system), I guess this is the
place to voice that opinion.

  [3]: http://elrond.aperiodic.net/shields/supported.html

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

Re: [Talk-us] Tagging a super-two highway (trunk or motorway?)

[Phil! Gold]

* Paul Johnson ba...@ursamundi.org [2013-06-25 09:40 -0500]:
 There seems to be some disagreement on how to handle the super-two (or
 super-four s California has a few of) highways.
[snip]
 I'm under the understanding that the consensus for a motorway would be
 fully multiple (at minimum 2) carriageway with limited access, whereas a
 trunk would be any motorway that doesn't meet that criteria (intersections,
 single carriageway, etc).

That matches my understanding.

Maryland Route 90 seems to be what people would call a super-two and,
although parts of it are divided, other parts have no physical separation.
For most of its length, it has no at-grade intersections.  When I was
doing TIGER cleanup in that area, I decided that highway=trunk fit better
than highway=motorway.  (Although NE2, somewhat unsurprisingly, decided
that he knew better and has retagged it highway=motorway with oneway=no on
the undivided sections.)

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

Re: [Talk-us] ref tags

[Phil! Gold]

* James Mast rickmastfa...@hotmail.com [2013-06-22 20:04 -0400]:
 Yep, here's picture proof that I personally took a few years ago of a Future 
 I-26 shield:
 http://img.photobucket.com/albums/v645/rickmastfan67/Interstates/NC/I-26/Img_2043s.jpg

Alright.  I'll add Future Interstate shields to my todo list.  Unless
everyone agrees on something else, I'll plan to key them off a tag of
network=US:I:Future .

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

Re: [Talk-us] Hamlets!

[Phil! Gold]

* Serge Wroclawski emac...@gmail.com [2013-06-21 09:17 -0400]:
 During the TIGER import, small neighborhoods were imported as hamlets.

I tend to think of the GNIS hamlets as small
places-where-people-live.  Around my section of the Baltimore suburbs,
most of them are housing developments, apartment complexes, trailer
parks or similar.  Some, however, do correspond to things that people
would more readily describe as towns or suburbs.  (Interestingly, none
of Baltimore's neighborhoods shoed up in the GNIS import.  All of the
GNIS place=* nodes stop at the city line.)

For the most part, I retag these nodes as landuse=residential unless I
am reasonably certain they correspond to a larger place designation,
in which case I give them an appropriate place= value.  I have
something of an advantage based on my location, because nowhere in the
immediate Baltimore metropolitan region is there a place that would
qualify as a hamlet (because the suburbs are all wide-ranging enough
to be place=village or, in some cases, place=town).

Note that I usually leave the nodes tagged landuse=residential, unless
I'm in the mood for figuring out subdividion boundaries based on
subdivision plats.  I know that the landuse= tags make more sense on
areas than on nodes, but it seems more correct to me than leaving the
node tagged place=hamlet.

 I'm wondering what other people's experience with the hamlets are. Are
 they useful where you live? Are they nonsense (as they have been in
 NYC and DC)?

I don't think they're nonsense.  I think most of them in my area
don't qualify for place= tagging, but most of them do correspond to
*something* that actually exists.  (Not all; if I can't match a node
to a place name or subdivision, I'll just delete it, but that's not
tremendously common in my experience..)

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
Hofstadter's Law:
  It always takes longer than you expect, even when you take Hofstadter's
  Law into account.
 --- --

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

Re: [Talk-us] Hamlets!

[Phil! Gold]

* Elliott Plack elliott.pl...@gmail.com [2013-06-21 21:01 -0400]:
 In the city of Baltimore, we have over 250 well defined neighborhoods, yet
 their boundaries are defined by a planning dept., not the people per se.
 Most of the neighborhoods have nodes place=suburb, but it probably should
 be place=neighborhood.

I put those there and at the time place=suburb seemed the best tag to
use; place=neighborhood wasn't yet in common use.  Based on my
understanding of current usage of the tags, most should probably be
place=neighborhood, but the larger or more prominent neighborhoods
(like Hampden or Fells Point) should get place=suburb, in a vein
similar to the distinctions between place=town/village/hamlet.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
#define NULL 0   /* silly thing is, we don't even use this */
   -- perl.c, perl source code
 --- --

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

Re: [Talk-us] ref tags

[Phil! Gold]

* James Mast rickmastfa...@hotmail.com [2013-06-22 07:22 -0400]:
 I do hope that the render will avoid using the Super relations.

My rendering doesn't use super relations (mostly[0]), because it
doesn't need to; the per-state relations contain all of the tags
needed for it to get the right shields.

 the segment of I-26 between I-240 and Exit #9 is still considered to
 be a Future Interstate and it is posted as such with FUTURE tabs
 above all I-26 shields on that segment (and missing the word
 Interstate in the shields itself.

Would it be worthwhile to declare a separate network for these
(US:I:Future seems natural) and give them their own relations?  If
there are signs on the ground, I could see about putting images in my
rendering for them.


[0] At lower zoom levels the rendering uses the osm2pgsql route
relation geometries for overview rendering of two-digit Interstate
shields, which might end up using super relations, if osm2pgsql
generates geometries from them, but that's a fairly minor part of
the rendering and only applies from zoom 7 to zoom 9.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
  kceee^ I hate users
knghtbrd you sound like a sysadmin already!
   -- seen on #debian
 --- --

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

Re: [Talk-us] ref tags

[Phil! Gold]

* Clay Smalley claysmal...@gmail.com [2013-06-20 09:26 -0700]:
 Also, even if it were the case that they were the same network, it makes
 sense to keep them separate because that is how the shield renderer
 determines which shield to put on the road.

My shield renderer is pretty flexible.  I can assign shields on a
ref-by-ref basis, if need be (though it means that networks' shields
require more maintenance in the long run).[0]  As long as the solution
has local consensus I'll find a way to work with it.[1]

[0] See, for example, Georgia route 515, which gets a blue sign because
it's part of an Appalachian Highway Development System corridor:


http://elrond.aperiodic.net/shields/?zoom=12lat=34.66561lon=-84.48668layers=B

[1] Or throw up my hands and say, I don't know how to handle that, but
that shouldn't impede consensus.  There are still a bunch of things I
don't have a good way to handle yet, like the way Tennessee does
primary and secondary state highways, or the way Maryland signs
Business US Highways.

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

Re: [Talk-us] ref tags

[Phil! Gold]

* Ian Dees ian.d...@gmail.com [2013-06-18 08:07 -0500]:
 Because no one's stepped up to do it!

Okay, I should probably put my toes in here.  I can spend this weekend
cleaning up my code (for http://elrond.aperiodic.net/shields/ ) and maybe
try to get it running on the US server, if there's interest/approval.
Note that it requires PL/python, which is an untrusted PostgreSQL
language, and takes some tweaking to get all of the pathnames set up
properly.

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

Re: [Talk-us] ref tags

[Phil! Gold]

* Jason Remillard remillard.ja...@gmail.com [2013-06-17 22:19 -0400]:
 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.

Note that the conventions for ref tags are different for relations and
ways.  A way that is tagged ref=I 70 should be a member of a relation
that is tagged network=US:I, ref=70.  (And a relation tagged
network=US:US:Business, ref=15, modifier=Business would correspond to a
way tagged ref=US 15 Business.)  This sort of adaptation might be a good
candidate for the Lua transformations recently added to osm2pgsql, but I
haven't had a chance to really look at those yet.

(Also, of course, such ref projection would need to take concurrencies
into account.  Sigh.)

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

Re: [Talk-us] ref tags

[Phil! Gold]

* Martijn van Exel m...@rtijn.org [2013-06-18 10:40 -0600]:
 Perhaps we can get together on IRC sometime soon and see what would need to
 be done. I can't make tonight but tomorrow early evening (like, 6PM MDT)
 would work. Ian, Phil, Toby, are you around then?

That's 8pm for me, which might work.  Depending on other stuff I have
going on that evening, I might not be available until 8:30 or so (EDT).
(Wednesday's my only free evening this week, so if it doesn't work I won't
be available until Saturday sometime.)

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

Re: [Talk-us] Admin boundary level quirk in NYC

[Phil! Gold]

* John F. Eldredge j...@jfeldredge.com [2013-05-18 09:49 -0500]:
 You might want to take a look at how Virginia is mapped.  Cities in
 Virginia are not considered to be subordinate to counties, even if
 surrounded on all sides by a county.

From what I've seen of Virginia, it seems to be mapped the way
Maryland has Baltimore City: independent cities are considered to be
coequal to counties and are mapped with admin_level=6, the same as
counties.  NYC is a little different in that the five boroughs are
counties that are subordinate to the city (which, I suspect, is why
NYC is currently mapped as admin_level=5).

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
The problem with using C++ ... is that there's already a strong tendency
in the language to require you to know everything before you can do
anything.
   -- Larry Wall
 --- --

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

Re: [Talk-us] [Imports-us] Baltimore Building Outlines Import

[Phil! Gold]

* Elliott Plack elliott.pl...@gmail.com [2013-05-04 09:43 -0700]:
 Building type: you might be able to tell if its classified
 residential or commercial or whatever from the GIS data.

Spatial queries should be able to tell that in combination with the
landuse shapefiles
( http://wiki.openstreetmap.org/wiki/Baltimore,_Maryland/Landuse and
https://data.baltimorecity.gov/Geographic/Land-use-Shape/feax-3ycj ),
although my only experience with doing that sort of thing has been
with PostGIS databases; I don't know if QGIS can do it on its own.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
I must first reveal my personal bias in this discussion, since I worship
at the First Church of PDF Really Sucks.
   -- Bruce Tog Tognazzini
 --- --

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

Re: [Talk-us] Baltimore Building Outlines Import

[Phil! Gold]

* Matthew Petroff openstreet...@mpetroff.net [2013-05-04 00:07 -0400]:
 My only qualm with the data is that some buildings have more nodes
 than they need, but I'm not sure what can be done about it besides
 manually reviewing and simplifying all 200k+ outlines.

My opinion on imports is that if manual intervention is the only way
to keep the data at the same quality level that OpenStreetMap should
be offering, then manual processes need to be part of the import,
because an import should not degrade the quality of data in OSM.
(This is why I rejected an direct import of the city's landuse data.
http://www.openstreetmap.org/user/asciiphil/diary/13891 )

When I briefly discussed the building footprint import with Elliott, I
said that, were I doing it, my process would involve pulling the
buildings into JOSM and using JOSM's todo plugin to look at each new
building and make sure it looks okay and migrate any tags from
existing OSM building data.  That's a lot more work than just bulk
processing the data and dumping it into OSM, but I think the
hand-cared aspects of our data are some of the most important things
about this project and imports should only complement that care.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
OOPS!  You naughty creature!  You didn't run Configure with sh!  I will
attempt to remedy the situation by running sh for you...
   -- Perl configure script
 --- --

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

Re: [Talk-us] Airport Tagging

[Phil! Gold]

* Rick Marshall rick.marsh...@verticalgeo.com [2013-04-23 12:37 -0500]:
 1.  How do you mark Precision Approach Path Indicator (PAPI), Visual
 Approach Slope Indicator (VASI), VOR, and other Navigational Aids at
 airports.

As far as I know, there isn't a widespread way of tagging these things.  I
turned up this wiki page:

  http://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dnavigationaid 

but using type= for the type of navigational aid is probably not the best
approach (because it's too generic as a tag and because it's already in
use for determining relation types).

I would probably do one of two things:

 1. tag a VOR, for example, as aeroway=navigationaid, navigationaid:type=vor 
and add something to the aeroway=navigationaid wiki page about using
navigationaid:type= instead of just type=.

 2. Join the tagging@ list, suggest the above as a general tagging scheme
and see what, if anything, comes out of the resulting discussion.  You
will need a fair bit of patience to go this route and it's a lot
easier if you have been working with OSM data (contributing,
consuming, or both) for a while first.

 When I tag my edits as aeroway=vasi or aeroway=papi they don't show up
 on the map. Is there a better way to tag the edits?

Not at the moment.  The main map rendering attempts to show a large subset
of the various things in the OpenStreetMap database, but it typically
doesn't go very deeply into specialized subsets of the data.  There are
other renderings that are more narrowly focused, like OpenSnowMap for ski
resorts and winter sports or ITO Map's railways view.  Things like these
navigational aids would probably only be rendered by a specialized air
traffic infrastructure map rendering, but I'm not aware of any such
renderings that actually exist at the moment.  (ITO Map has an airport
details map at http://www.itoworld.com/map/163 , but it's pretty
rudimentary.)

 2.  Who decides the geographical limits of an aerodrome?

Normally, it should be the land specifically (and, usually, legally) set
aside for it.  This approach tends to work best for larger and
dedicated-use airports.  For smaller facilities where the land is
shared-use (e.g. a farm that has an airstrip on it), either you do your
best to outline only the land that is exclusively for air traffic or you
just put a node roughly in the middle of the area with the aerodrome tags
on it.

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

Re: [OSM-talk] RFC updated: OSM Attribution Mark (was: contributor mark)

[Phil! Gold]

* Alex Barth a...@mapbox.com [2013-04-22 08:40 -0400]:
 2. A completely redesigned mark, containing the letters OSM

I like it.  Definitely more distinctive and specific to OSM than the
hammer icon.

 3. A completely redesigned `/copyright` page, the page the mark links to.
 It is much closer to today's `/copyright`

I think the new copyright page is very nice looking and presents its data
well, but I, personally, still find it a little confusing in that there
are very few visual cues that you can scroll down.  My first impression
(as with the previous copyright page) is that it's just a pretty
attribution page that serves merely to write out the word
OpenStreetMap.  All of the additional information is below the bottom of
the page and I didn't find it obvious that there would be anything down
there.

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

Re: [OSM-talk] Osm2pgsql/TileMill - how to detect whether way is in a route?

[Phil! Gold]

* Steve Bennett stevag...@gmail.com [2013-03-19 10:52 +1100]:
 One way to fudge this is to render the way, then render the route
 relation over the top, obscuring it. But that doesn't work if you want
 to use line smoothing (eg, line-smooth:0.6). The route relation will
 form a smooth bezier curve the intersection of two ways, but the way
 rendering will form a sharp point.
 
 So I'm just wondering if there is a way around this - some setting in
 osm2pgsql, some SQL magic I could play with.

I do something very similar with my highway shield rendering, which is
driven by route relations.  I go through the planet_osm_rels table that's
created by osm2pgsql's slim mode, which is considered cheating in some
circles.

My rendering has code at https://launchpad.net/osm-shields , but the meat
of what you're interested in is the following two functions:

-- osm2pgsql stores tags in PostgreSQL arrays, where even-numbered array
-- members are tags and odd-numbered members are the tags' values.  This
-- is a convenience function to go through such an array and retrieve the
-- value for a given tag.
CREATE OR REPLACE FUNCTION osm_get_tag_value(tags TEXT[], tag TEXT)
RETURNS TEXT
IMMUTABLE
RETURNS NULL ON NULL INPUT
LANGUAGE plpgsql
AS $$
DECLARE
  tag_index INTEGER;
BEGIN
  SELECT i INTO tag_index
FROM (SELECT generate_subscripts(tags, 1) AS i) AS indices
WHERE i % 2 = 1 AND tags[i] = tag;
  RETURN tags[tag_index + 1];
END;
$$;

CREATE OR REPLACE FUNCTION 
shields_get_route_memberships(planet_osm_rels.id%TYPE)
RETURNS fullref[]
STABLE
RETURNS NULL ON NULL INPUT
COST 5000
LANGUAGE SQL
AS $$
  SELECT 
shields_replace_groups(array_agg(ROW(shields_sanitize_text(network), 
shields_sanitize_text(ref))::fullref))
FROM (SELECT osm_get_tag_value(tags, 'route') route,
 UPPER(osm_get_tag_value(tags, 'network')) network,
 UPPER(COALESCE(NULLIF(osm_get_tag_value(tags, 'ref'), ''), 
osm_get_tag_value(tags, 'name'))) AS ref
FROM planet_osm_rels
WHERE parts  ARRAY[$1]
  AND parts[way_off:array_upper(parts, 1)]  ARRAY[$1]) AS 
ref_inner
WHERE route = 'road' AND network IS NOT NULL AND ref IS NOT NULL;
$$;

There's a lot of shield-rendering-specific code in there.  A more succinct
query might be the following (where $1 is the OSM ID of the way for which
you want to determine route membership):

SELECT *
  FROM (SELECT osm_get_tag_value(tags, 'route') route,
   osm_get_tag_value(tags, 'network') network,
   osm_get_tag_value(tags, 'ref') ref,
   osm_get_tag_value(tags, 'name') name
  FROM planet_osm_rels
  WHERE parts  ARRAY[$1]
AND parts[way_off:array_upper(parts, 1)]  ARRAY[$1]) AS 
ref_inner
  WHERE route IS NOT NULL;

Obviously, you can add your own parameters in the statement.

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

Re: [OSM-talk] a license violation?

[Phil! Gold]

* Robin Paulson ro...@bumblepuppy.org [2013-01-02 23:41 +1300]:
 i was looking for unusual uses of osm data, and found this:
 
 http://store.axismaps.com/product/boston-blue
 
 osm is mentioned on the web site, but not on the poster itself.

I have their DC poster and I'm pretty sure there's an attribution at the
bottom of the poster.  It's at home and I'm not, so I'll have to wait
until this evening to check it out.

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

Re: [Talk-us] parcel data in OSM

[Phil! Gold]

* Jason Remillard remillard.ja...@gmail.com [2012-12-28 16:16 -0500]:
 So the question is, what should the exact criteria be for including an
 open space parcel in OSM. Consider some of the various types of
 property.

I've used parcel data as a layer in JOSM to trace from.  It lets me be a
little more accourate about some area boundaries than I could from just
aerial imagery (and walking a GPS along, say, the border between a golf
course and a residential area with private houses is a little out of the
question).

I'd be resistant to the idea of bulk import (pretty much anything beyond
pulling individually-checked polygons into OSM) because I've seen a lot of
places where a naive import of the parcel data available would have made
for wrong or at least weird OSM data.

I've seen a number of places where a single entity acquired its land over
time, so the parcel records show multiple parcels that should be a single
OSM entity.  Similarly, I've seen a lot of places where a public road cuts
through a single entity's land (golf courses especially, but also parks
and residential areas).  I feel it's more correct to make a single polygon
that crosses the road, but parcel data would usually have the road
splitting the area.  I've also seen a few places where parcels were too
broad, where a single parcel needs to be divided into several different
OSM landuses.

This is just my experience with the handful of counties in Maryland that
have parcel data available under an OSM-friendly license.  Maybe other
jurisdictions have data that would provide a more one-to-one
correspondence with OSm features.  Even in those cases, an importer would
need to make sure that the import fits topologically into OSM, interacting
properly with existing data.

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

Re: [Talk-us] Fixing shorelines

[Phil! Gold]

* Eric H. Christensen e...@christensenplace.us [2012-12-13 21:54 -0500]:
 On Thu, Dec 13, 2012 at 02:23:52PM -0500, Phil! Gold wrote:
  If you use JOSM, the ContourMerge plugin is very helpful here.
 
 Thanks for the advice.  I've tried that technique and it seems to have
 done what I wanted but I'm withholding judgment until I actually see the
 results on the website.

That might take a while.  The data used to render coastlines is generated
irregularly on approximately a monthly basis.  You can take a look at an
area a little ways north where I've done the same thing:
http://osm.org/go/ZZfHNr1i .

 I've not been very impressed by the TIGER roadway data in my little town

Yeah.  The TIGER data for Anne Arundel County was really horrid at the
time of the import.  I've cleaned up a bunch of it in the northwest corner
of the county (areas near BWI, Fort Meade, and Laurel), but there's a lot
left to do.

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

Re: [Talk-us] Fixing shorelines

[Phil! Gold]

* Jeff Meyer j...@gwhat.org [2012-12-13 12:58 -0800]:
 On Thu, Dec 13, 2012 at 11:23 AM, Phil! Gold phi...@pobox.com wrote:
  I use tilestache to go between
  JOSM's tile underlays and the ArcGIS REST interface).
 
 Do you have a pointer to any docs of how to do this?

It's pretty simple.  You use tilestache's URL template provider to proxy
requests to the REST server.  It works as long as the server supports the
web mercator projection, which might be under any of the SRIDs 900913,
102113, 102100, 3785, or 3857.  (The last is the current official code
from EPSG.)  Here's what I use for Anne Arundel County's orthoimagery:

{
  layers: {
AAOrtho2010: {
  provider: {
name: url template,
template: 
http://gis-world.aacounty.org/ArcGIS/rest/services/Ortho2010/MapServer/export?f=imagebboxSR=102113bbox=$xmin,$ymin,$xmax,$ymaxsize=$width,$heightformat=png24;
  },
  preview: {
lat: 38.974,
lon: -76.595,
zoom: 10
  }
}
  }
}

For their vector-based data, I add `transparent=true` so I can overlay it
on aerial imagery:

AABasemap: {
  provider: {
name: url template,
template: 
http://gis-world.aacounty.org/ArcGIS/rest/services/Basemap/MapServer/export?f=imagebboxSR=102113imageSR=102113transparent=truebbox=$xmin,$ymin,$xmax,$ymaxsize=$width,$heightformat=png;
  },
}

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

Re: [Talk-us] Dual Carriageway?

[Phil! Gold]

* Jim McAndrew j...@loc8.us [2012-11-29 12:18 -0700]:
 From looking around on OSM, it doesn't seem like people are marking roads
 with a garden in the middle of the road as a dual carriageway, maybe they
 should be?

For short islands in the middle of a road (like the links you gave), I
usually don't map as a dual carriageway unless it makes a difference to
routing (i.e. there's a road that only connects to one side of the
island).

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

Re: [Talk-us] TIGER expansion bot

[Phil! Gold]

* Serge Wroclawski emac...@gmail.com [2012-11-27 11:33 -0500]:
 On Tue, Nov 27, 2012 at 11:07 AM, Brian May b...@mapwise.com wrote:
  Another clarification for this use case:
  A user changes the original highway name tag from Main St SW to SW Main
  Street, but did not alter the tiger tags.

 I haven't seen any examples of this that seemed to expand incorrectly
 in my surveys of results.
 
 Are you able to point me to actual examples of this in the OSM US dataset?

How would your bot handle this way?  
http://www.openstreetmap.org/browse/way/5321758
As one might expect, the name was corrected by a local who knows his
street name but not necessarily all the tiger: tags.  IMHO, nothing of
this sort should be touched by a bot.

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

Re: [OSM-talk] obsolete TIGER-tags

[Phil! Gold]

* Mike N nice...@att.net [2012-11-20 13:58 -0500]:
 I also remove reviewed when I have verified the geometry and general
 road type, although others use the reviewed flag as a a sign that it has
 been verified on the ground.

Yeah, I only remove the tiger:reviewed tag once I've verified both the
geometry and the name.  If I've only verified the geometry (i.e. I haven't
yet done a ground survey there), I change it to tiger:reviewed=position.

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

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

[Phil! Gold]

* Steven Johnson sejohns...@gmail.com [2012-11-17 18:45 -0500]:
 http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/UnitedStates

From my perspective, addr:street_prefix and addr:street_type don't seem
that useful, since I don't see how they add information that's useful to
data consumers and they require extra work from data contributers.
If I understand things, the proposal would take a way tagged with
name=Old Frederick Road and add addr:street_prefix=Old,
addr:street_type=Road.  What benefit is there to that?  (Put differently,
what motivation can you give to convince mappers that it's worth their
time to add those tags on every road whose name they modify?)

It's also worth considering how a tagging scheme can be broken.  It's not
uncommon for contributors to edit one tag and fail to notice related tags
on the same object.  How would you suggest handling, say, name=Wentworh
Avenue, addr:street_type=Road?

I do think there's a use case for directional prefixes that are not
strictly part of the road name, but are instead for addressing.  Many
parts of the US have roads with addresses of the form 10 North Something
Street where the road signs emphasize Something Street and the North
or South parts are less visible.  (I've seen many roads in my area where
the signs for such roads are not even consistent in terms of whather it's
a prefix or suffix; adjacent signs might show both N Something St and
Something St N.)  In these cases, I think it would be beneficial to have
tagging of the form name=Something Street, addr:direction=North so
routers can tell people things like, Turn left on Something Street,
which reflects the signage, but geocoders can figure out where addresses
are likely to be even in the absence of complete address information.
(This sort of usage would require proposing changes to address tagging, as
well as road tagging.)

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

Re: [Talk-us] US State Shield rendering - Modifiers

[Phil! Gold]

* Mike N nice...@att.net [2012-11-13 09:38 -0500]:
 WOOT!  We may have hooked a new US mapper because of the shield
 rendering on the test shield development server!

Awesome!

   That leads to a related question - what is the best way to tag for
 modified state routes.   For example in South Carolina:
 
   State route 49 -  US:SC , ref = 49(That is clear)
   State Route 49 Bypass -  US:SC:Bypass , ref = 49 , modifier = Bypass
   State Route 49 Truck  -  US:SC:Truck , ref = 49 , modifier = Truck
   State Route 49 Business - US:SC:Business , ref = 49 , modifier = Business

This matches the on-list consensus on the topic and is what the shield
rendering currently understands.

   State Route 49 Truck Bypass -  US:SC:Truck:Bypass , ref = 49 , modifier = 
 Bypass:Truck   (in any order)

This would also match the list consensus.  In the absence of any
compelling reason not to, I've set up the rendering to accept modifiers in
any order, so it would treat US:SC:Truck:Bypass and US:SC:Bypass:Truck
identically.

Personally, I'd probably tag modifier=Bypass;Truck, with a semicolon, to
match multi-value usage in other tags.

   What do we need to do to enable shields for this?

Well, someone could put together the necessary sequence files and template
images, if needed, and send me either a merge proposal or a patch from the
code at https://launchpad.net/osm-shields.

Alternately, I can set them up if you can get me some images of what the
bannered shield signs look like and a list of bannered routes in South
Carolina.  (I can manage with just the reference images if you're okay
waiting until I notice the unmatched routes in the OSM data.)

I've gotten a bit behind in code maintenance--the most recent reason being
a new job that's absorbing more of my time than usual--but I hope to get
back to the shield rendering soon.  (Take heart, Minh Nguyễn, I'll get the
Ohio county routes in yet.)

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

Re: [Talk-us] What to do with unnamed NHD streams

[Phil! Gold]

* Paul Norman penor...@mac.com [2012-10-28 20:51 -0700]:
 A sensible solution in any NHD translation may be to drop any FCode 46003
 (intermittent) streams without a name. It may also be worth dropping FCode
 46006 (perennial) streams without a name.

I do a lot of tracing streams from aerial imagery with the NHD as an
overlay for names and pointers as to the flow locations.  (I prefer
tracing to importing because I can achieve much better accuracy than the
NHD, plus I ensure that the waterways interact properly with roads by
adding bridges and tunnels as necessary.)

Based on my experience with the NHD, I think an import should probably
include FCode 46006 streams; I've seen quite a few decent-sized streams
without names that I feel definitely enhance the map by their presence.  I
probably wouldn't have objections to removing FCode 46003 streams, but be
aware that the NHD is the product of a lot of different people entering
data over a span of many years (sound familiar?) and the threshold between
46006 and 46003 can vary significantly from area to area, presumably
depending on the judgement of the pople entering the data.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
Miskatonic University Alumni Association
Go pods!
 --- --

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

Re: [OSM-talk] OSM Legal in OSM reimplementation project

[Phil! Gold]

* john whelan jwhelan0...@gmail.com [2012-08-16 14:58 -0400]:
 Could some consideration be given to grandfathering, ie if your existing
 use of our data is non profit or government and you are not supplying our
 data to third parties then you are permitted to continue to use the data as
 if it was CC-by-SA.  This would avoid the problem of delays whilst approval
 is obtained once more.

I would presume that anyone who needs time to put the license change into
effect would continue to work off the last CC-BY-SA planet file (or the
last pre-redaction CC-BY-SA planet file), without consuming updates of
course, until they're ready to work with ODbL data.

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

Re: [Talk-us] Another random road reclassification

[Phil! Gold]

* Toby Murray toby.mur...@gmail.com [2012-08-14 23:26 -0500]:
 http://www.openstreetmap.org/?lat=39.117lon=-94.8924zoom=14layers=M
 
 I know there is some disagreement about road classification,
 especially when it comes to trunk but I'm pretty sure most people
 would agree that this is incorrect. Thoughts?

I agree with your assessment.

In my opinion, road classifications are most useful when applied over
significant stretches of road.  I don't think a rural freeway that has
someone's driveway on it needs to be dropped from motorway to trunk around
that driveway, and I don't think a divided expressway with mostly at-grade
intersections but a few interchanges should be upgraded from trunk to
motorway around the interchanges.

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

Re: [OSM-talk] OSMF Board auto industry / What's the story?

[Phil! Gold]

* Maarten Deen md...@xs4all.nl [2012-08-09 14:55 +0200]:
 Just curious: what is the current legal stand on mixing OSM with
 proprietary information? Let's say I want to use the OSM map and I
 have bought a proprietary list of POI's. Am I allowed to combine
 this, convert this to my proprietary format and distribute this,
 only giving credit?

As I understand it (and, of course, legal-talk@ is that way --), under
the ODbL, if you mix your own data into OSM data and distribute the
result, you must give any users access to your mixed database and license
that database to them under the ODbL (or give them your POI list and
whatever programs are necessary to mix the two datasets).  You have to
provide this data in a reasonably-accessible format.  CC-BY-SA is similar
in broad terms (you must license the mixed database to the user under
CC-BY-SA), but lacks the details more specific to datasets, like the
reasonable-format requirement.

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

Re: [Talk-us] Discardable TIGER tags

[Phil! Gold]

* Alan Mintz alan_mintz+...@earthlink.net [2012-07-29 18:54 -0700]:
 [1] When combining ways in JOSM (at least), values for tiger:* tags
 are combined with : (colon) as a delimiter, instead of ;
 (semi-colon). Why, and should this be changed?

I believe this behavior was intended to make tiger:tlid merging work a
little better.  As I understand it, the TIGER data originally imported was
structured so that a single road was composed of many segments connected
end-to-end.  For the import, all segments with the same data values were
concatenated into a single way and the IDs of each constituent segment
were concatenated, separated by colons, and stored in the tiger:tlid tag.
Thus, when combining two TIGER ways, using a colon to join their
tiger:tlid tags would give a roughly correct reflection of the mapping
between TIGER data and OSM data.  I don't know why the decision was made
to apply that to all tiger: namespace tags rather than just the tiger:tlid
tag.

Obviously, this doesn't help with way splits; the tiger:tlid value gets
copied to each half, even though the original segments are now divided
across the two ways.  On top of that, TIGER doesn't use the segment
structuring anymore; their data is more like OSM now, and each road gets a
feature ID that's unrelated to the old TLIDs (though there might be a
table somewhere providing a correlation between the two systems).  Given
all that[0], it seems reasonable to drop tiger:tlid on edits like the
created_by tag.


[0] Plus my personal experience that I periodically have to delete
tiger:tlid tags after merging ways because the resulting tag value
exceeds OSM's length limit.

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

Re: [Talk-us] Post bot cleanup

[Phil! Gold]

* Mike N nice...@att.net [2012-07-19 17:01 -0400]:
  FYI in South Carolina, I'm volunteering to clean up the
 northwestern part of the state because I have some local knowledge.

Cool.  I've just finished looking over I-20 and repairing all the roads
that were split to make bridges over it.  I mostly left them classified
highway=residential; I'd prefer to leave road classification to someone
more familiar with the area.

I plan to start cleaning up I-95 next; it looks like it's got big chunks
missing, among other problems.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
For every meme, there is a Cafe Press shop, where you can buy t-shirts,
mugs, and thongs.
   -- Xeni Jardin
 --- --

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

Re: [Talk-us] Post bot cleanup

[Phil! Gold]

* Toby Murray toby.mur...@gmail.com [2012-07-19 00:42 -0500]:
 Any other common problems that people have seen?

Probably the most common thing I've seen is what TIGER road splits look
like: one way (usually leading up to a bridge), followed by a string of
unconnected nodes.  Fixing these is pretty easy: click along the
unconnected nodes to draw a way connecting them (and recreate the bridge
or whatever, of course).  Having Bing or other imagery underneath helps
you know when to stop or keep going.

I've also seen a bunch of motorway_links without oneway tags, so that's
definitely something to keep in mind.  Are there other important,
non-obvious tags that it would be good to specifically be checking for?

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
Science is built up of facts, as a house is with stones.  But a collection
of facts is no more a science than a heap of stones is a house.
   -- Jules Henri Poincare
 --- --

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

Re: [Talk-us] Post bot cleanup

[Phil! Gold]

* Martijn van Exel m...@rtijn.org [2012-07-19 14:22 -0600]:
 On Wed, Jul 18, 2012 at 11:42 PM, Toby Murray toby.mur...@gmail.com wrote:
  Any other common problems that people have seen?
 
 Another thing I find is a lot of leftover stray nodes without any tags.
 I select them in JOSM with type:node tags:0 -child and delete them in
 one fell swoop.

Eeek!  Be very careful with this!  The unconnected, untagged nodes were
left deliberately to facilitate recreation of roads, particularly the case
where a decliner split a TIGER way but did not change its geometry.  I've
been making use of these nodes in South Carolina to reconstruct the roads
there.

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

Re: [Talk-us] LA part of the map essentially is unusable

[Phil! Gold]

* Charlotte Wolter techl...@techlady.com [2012-07-19 15:58 -0700]:
 That's great, but will it overwrite work that we've already
 done?

Presumably not.  Potlatch loads shapefiles into a separate layer and
requires mappers to manually pull the data into OSM.

 Also, is this something that works only in JOSM, in which
 case many of us couldn't use it?

No.  For one thing, Richard is the main developer of Potlatch and doesn't
do anything with JOSM.  For another thing, he mentioned reworking the P2
source code; P2 refers to Potlatch 2.

 Also, I still don't understand why all the TIGER data was
 deleted on ways that were partially deleted.

Because of OpenStreetMap's data model.  When you split a way, what your
editor does is upload a changed version of the original that only
contains half the original nodes and then upload a new way with the same
tags as the old one that contains the other half of the nodes.  To
subsequent database queries, the second way appears as though you created
it and there's no direct link back to the way that originally contained
the nodes.

On top of that, there was a deliberate decision made (as I understand
things) not to undo deletions, which includes the removal of nodes from a
way.  Had the bot done that, there would be many places where the bot
would create multiple, overlapping, tangled ways.

Since either approach would have left significant messes for mappers to
clean up, there wasn't really a good way forward.  The people working on
the redaction bot felt that not undeleting would be the better of two bad
options.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
i am not interested in a penis for aesthetic purposes.
   -- isabelle whitman
 --- --

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

Re: [Talk-us] Redaction bot is heading our way!

[Phil! Gold]

* Kai Krueger kakrue...@gmail.com [2012-07-18 18:26 -0700]:
 Chris Lawrence-2 wrote
  I've fixed up I-20 between the Columbia River and US 21
 
 I also started fixing the I-20 at the intersection to I-77

I also started working on I-20, from the Georgia border.  (I had qualms
about just going with the first one Wikipedia listed on their numbered
routes in South Carolina page...)  I spent a bunch of time reconstructing
the roads that cross it, though; for a lot of them, all the
decliner/non-responder did was split them to make bridges, which ends with
the road still on one side of the Interstate and a line of nodes on the
other side, so it's not too hard to recreate the roads.

 The question is, is it better to fix up a small bit thoroughly, or try
 and get as much of the interstate at least vaguely right as soon as
 possible, and leave the rest to a second pass?

IMHO, interstate connectivity is most important, but I figure reconnecting
roads that were split to cross the interstate will get decent other chunks
of the road network functional, too.

 Unfortunately, I think I also ran into an editing conflict with you, as when
 I wanted to upload my changes, potlatch complained about version miss match
 on the I-20 relation.

I hit a conflict with someone, too, but I think I correctly integrated
both sets of changes.  It helped that the other person had been working on
a different area of the relation, and neither of us had drastically
reordered the relation members.

 So another question is, what is the best way to coordinate the general
 fixing of the interstate system to try and minimize editing conflicts?

I'm not sure.  Maybe listing the Interstates (and perhaps US Highways) on
the wiki and letting people claim them one by one?

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

Re: [Talk-us] Scenic/Historic byways

[Phil! Gold]

* Toby Murray toby.mur...@gmail.com [2012-07-08 14:20 -0500]:
 Closer to home I have also seen a Scenic Byway sign. This seems to
 be an official designation by the US DOT as discussed here:
 http://en.wikipedia.org/wiki/National_Scenic_Byway

I've done a bit of reading about these, mostly as they pertain to
Maryland.  It appears that most of those are also state-designated scenic
byways, and a state will probably have other scenic byways that are not
nationally recognized.

 So how do we map these?

In Maryland, the state has a brochure showing more or less where the
byways are, and they're not entirely consistently signed[0].  I've put one
into OpenStreetMap[1] and tagged it much as you did the Western Vistas
Historic Byway, but I used a network of US:MD for lack of a better
option.  (US:MD:Scenic Byway might make sense, too.)

I think the state-based scenic byways should have state-specific network
tags.  There are a few that are not state scenic byways, like Skyline
Drive in Virginia.  I'm not sure what would be a good network for those.

I think the best way to handle National Scenic Byways and All American
Roads is just to add national_scenic_byway=yes and all_american_road=yes
tags (sorry) to the route relations as appropriate.  That probably doesn't
address your Historic Byway, but I haven't read anything about those.


[0] I've been on three of Maryland's scenic byways since I started paying
attention to them, and have only followed one for its entire length.
That one (the Horses and Hounds Scenic Byway) only has signs right
before the byway turns onto other roads and those signs do not
indicate which way the byway turns.  The Catoctin Mountin Scenic Byway
(also a National Scenic Byway) more or less runs along the entire
length of US 15 in Maryland and has signs dotted along the side of the
road.  The Star Spangled Banner Scenic Byway runs along most of the
length of the Baltimore-Washington Parkway, but I've only seen one
sign on the B-W Parkway--on the northbound side, just before MD
175--and it doesn't have the name of the scenic byway on it.

[1] http://www.openstreetmap.org/browse/relation/2188238

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

Re: [Talk-us] Rails with trails

[Phil! Gold]

* Nathan Edgars II nerou...@gmail.com [2012-06-27 12:59 -0400]:
 But another popular kind of rail trail, a rail with trail, cannot
 be found in this manner.
[snip]
 Does anyone have any ideas for tagging? The simplest would be
 something like rail_with_trail=yes or maybe railway=adjacent.

Either of those would work.  Between those two, I'm inclined toward
railway=adjacent so the search would be something like
highway=(path|footway|cycleway) and railway=(abandoned|adjacent).

Another possibility would be to use rail_trail=yes, which would apply to
any rail trail.  It would be implied by a non-motor-vehicle highway= tag
and railway=abandoned, but could always be specified to be unambiguous.

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

Re: [Talk-us] holes in Columbus OH?

[Phil! Gold]

* Peter Dobratz pe...@dobratz.us [2012-06-12 00:45 -0400]:
 There seem to be a lot of holes in the multipolygon relation, and it
 seems strange to me that there are so many places within the city that
 are not part of the city.  Is anyone more familiar with this area that
 give an explanation for this?

It's not uncommon for cities to have unusual shapes, including holes like
that, as they can have annexed land around but not within a given area.

In the specific case of Columbus, the holes look legitimate.  I looked up
Columbus on Wikipedia and found this map of the city:

  https://en.wikipedia.org/wiki/File:Columbus_Overview_Map-150dpi.png

The white part is the city proper and the colored parts are independent
suburbs, which seems to match (to a first approximation) the OSM data.

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

Re: [OSM-talk] Import guidelines review

[Phil! Gold]

* Tirkon tirko...@yahoo.de [2012-06-06 21:11 +0200]:
 Worst Fixer worstfi...@gmail.com wrote:
 It means that we must revert things like TIGER and CanVec. Am I right?
 
 I think fundamentally you are right with this point. My impression is
 that many people at OSM regret these imports - in fact the longer they
 are involved in the project.

I can only speak for myself, but I'm happy that TIGER was imported.  I
grumble about its quality problems and quirks all the time, usually while
I'm fixing them, but I think the US is much better off with that import
than it would have been without it.  I've only been here for a couple of
years, so maybe I haven't been around long enough to regret it, but I
probably wouldn't have gotten started with OSM if the TIGER-imported
framework hadn't already made it reasonably useful to start with.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
The universe is complex, but it's usefully complex.
   -- Larry Wall
 --- --

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

Re: [Talk-us] UVM-SAL Buildings

[Phil! Gold]

* William Morris wboyk...@geosprocket.com [2012-05-31 21:25 -0400]:
 Trying this again, after a hiatus, here is a sample of a few hundred
 buildings from a UVM-SAL land use classification. In this case it's
 for an area just west of D.C. in Montgomery County, MD. I offer it for
 your consideration before I pull the import trigger:
 
 http://dl.dropbox.com/u/23616645/Geosprocket_Share/mont_b_1.osm

I share the reservations already expressed about the nodiness and
blobbiness of the buildings.  Here's one set of buildings, shown against
Maryland's aerial imagery:

  http://static.aperiodic.net/tmp/md-mo-bldgs.png

I'm not convinced that a county full of blobs like that will look good on
the map and, thus, whether it would be an improvement over letting mappers
put the buildings in as they get to them.  I'm more comfortable with
things like the building import done a few months ago around Salisbury in
eastern Maryland where the data is much cleaner and, I think, better
serves as a basis for further improvements from local mappers.

I think that this level of accuracy, while reasonably-well-suited to
landcover data, isn't really good enough for buildings.

I'm also over in Baltimore County, so I'd like to hear what other regional
mappers think.

 Some steps I've taken to make it community-friendly include:
 
 - Removed all buildings that intersected existing OSM features

Definitely an important step.  Thank you.

 - Removed all buildings smaller than 5000 square meters in area, since
 those residential structures weren't being very well-detected anyway

There's not really a good cutoff for this, though.  I saw a couple of
housing developments with blocks of townhouses where random sets of
townhouses were missing.  Presumably the missing ones fell below your
threshold while most of the blocks didn't.  It might be useful to go much
higher and target just the largest buildings (which would also be the more
significant landmarks).  Over all of your data, what does the distribution
of building areas look like?

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
Go climb a gravity well!
 --- --

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

Re: [OSM-talk] TomTom is thumping us

[Phil! Gold]

* John Sturdy jcg.stu...@gmail.com [2012-05-29 09:15 +0100]:
 The nearest they make to an accurate point is classification of
 footpaths as roads --- I don't think I've seen any of those, but I
 have found quite a few unclassified roads that look more like
 tracks on Bing (and have adjusted them accordingly where confident
 of it).

I don't know if this is what they're talking about, but the TIGER data in
the US has more than a few footways, particularly wider, paved ones,
recorded as roads, which got imported into OSM as highway=residential.
(There are a lot of logging roads, 4x4 trails, and similarly
difficult-to-travel things also classified highway=residential.)  I fix
them as I find them, naturally, but it's a flaw in the TIGER dataset
(which I still think we're better off having imported).

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
  Londo, are you deliberately trying to drive me insane?
  The universe is already mad.  Anything else would be redundant.
   -- Vir and Londo (Babylon 5, Dust to Dust)
 --- --

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

Re: [Talk-us] Abbreviation expansion - USS to United States Ship?

[Phil! Gold]

* Kate Chapman k...@maploser.com [2012-05-10 14:01 -0400]:
 I think if we were too look at what is on the sign I bet it is U.S.S.
 
 MLK though often fully spells out the name on the sign.
 
 I would think in these cases it should be what is on the sign. Since
 it isn't an abbreviation of the road type, but the actual street name.

I agree.  I've made similar decisions about stuff in my area.  The right
of way of the old Washington, Baltimore and Annapolis Railroad has been
repurposed in various places.  One part is a road signed as WBA Road,
which I've opted to tag as name=WBA Road.  Another part is a hike/bike
trail often referred to as the WBA Trail, but officially called the
Washington, Baltimore and Annapolis Trail, so I've tagged it as
name=Washington, Baltimore and Annapolis Trail.  (Coincidentally, as I
looked at the map to check my tagging, I saw that another part of the WBA
right of way is a Martin Luther King Jr Highway.)

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
(format t ~@? (format t \~~@?\ ~:*~S))
 --- --

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

Re: [Talk-us] Highway Shield Rendering

[Phil! Gold]

 agree with this. From the point of view of using the data to
 make maps, I like this approach better than a separate modifier tag.


It was based on that thread and the previous one (Use of ref-tag on state
highways) that I felt there was a reasonable consensus in favor of
network-classification-per-banner, based on the fact that only one person
objected to it.


Apr 02, 2012: Highway Shield Rendering
gis.19327.n5.nabble.com/Highway-Shield-Rendering-tp5612357p5612357.html

Hey, that's this thread!

Chris Lawrence (the person who originally wrote the bit on the wiki about
using the modifier tag) appears to also support
network-classification-per-banner:
 After more thought, in the general case, deprecating modifier and just
 using network to denote variations using the established : separator
 convention is probably sanest.

Paul Johnson feels as NE2 does that this means that the network tag no
longer represents a distinct network (and that's a bad thing):
 Well, that kind of breaks the whole network concept then, and the
 key should probably be renamed to fit the expected data...

Craig Hinners, although comfortable using the network tag to represent
distinct network subsets separately from their mainline portions, doesn't
like using it to mark geographically-distinct signage for what's otherwise
the same network subset:
 Phil! Gold phi...@pobox.com:
  It seems to me that network=US:US:Business:MD is the logical extension of
  a scheme that has US:US and US:US:Business.
 
 My initial reaction is that this goes too far in mixing geographic,
 classification, and rendering concepts, which has a bad smell

Michal Migurski says he's used the modifier tag as a data consumer:
 For what it's worth, as a renderer I preferred the modifier tag when
 doing the Terrain shields:
 http://maps.stamen.com/terrain/#13/34.0510/-118.2146
 
 Modifiers in the ref tag would be a close second; those typically need a
 lot of scrubbing and normalization an yway.
 
 In the network tag would be the biggest hassle of all.

I mostly support the network-classification-per-banner (though from a
coding perspective, the alternatives would be just as much work for me to
handle):
 I think this highlights a reason to use network subsets in the network
 tag: because it's a simpler rule to apply than deciding whether a
 variant route is different enough to deserve its own network value.


If you count out all the emails on the subject, there are probably more
emails opposing the network-classification-per-banner approach, but if you
count the people expressing opinions on the matter,
network-classification-per-banner has a strong majority.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
I smell a wumpus.
 --- --

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

Re: [Talk-us] Highway Shield Rendering

[Phil! Gold]

* Nathan Edgars II nerou...@gmail.com [2012-04-12 15:52 -0400]:
 On 4/12/2012 2:59 PM, Phil! Gold wrote:
 * Minh Nguyenm...@1ec5.org  [2012-04-12 10:06 -0700]:
 There's an ALT I-75 that needs its own sequence file
 
 I wouldn't necessarily oppose a separate network tag in this case, since
 it's clearly not part of the Interstate Highway System. (The same would
 apply to business Interstates.)

* Nathan Edgars II nerou...@gmail.com [2012-04-12 16:03 -0400]:
 Also I-270 Spur in Maryland, which *is* part of the Interstate
 Highway System and thus belongs in network=US:I

First off, I still feel that there was a consensus last year on using the
network tag for distinct network subsets as well as for mainline roads and
you, despite being the only dissenter, continue to argue against something
the rest of community more or less settled on.

Secondly, I think this highlights a reason to use network subsets in the
network tag: because it's a simpler rule to apply than deciding whether a
variant route is different enough to deserve its own network value.  You
seem to have a clear idea about what constitutes a network from your
perspective--Interstate 75 Alternate and Downtown Interstates do, but
Interstate 270 Spur doesn't.  I think there's a lot of grey area where
people with different perspectives would disagree[0], especially mappers
who just want to represent what they see on the signs where they live
without arguing the minutiae of which road network a route is really a
member of.

In short, you seem to want to have the final say about what is or isn't a
real network, but OpenStreetMap is a community effort and not only does
the network tag can have distinct values for network subsets scheme
appear to have broader community support, but it also seems to me to be
the most generally applicable by people who in all likelihood will have
different opinions about what *really* constitutes a distinct road
network.


[0] I feel, for instance, that I could make a convincing argument either
way as to whether Texas's loop roads should count as their own network
or should be part of the state's main network.  Likewise for routes
signed as US 1, US 1A, and US 1 Alternate.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
How do RPG characters manage to carry so much?  Very deep pockets.
   -- MenTaLguY
 --- --

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

Re: [Talk-us] Network tag Re: Highway Shield Rendering

[Phil! Gold]

* Paul Johnson ba...@ursamundi.org [2012-04-11 17:33 -0700]:
 On Apr 11, 2012 11:48 AM, Phil! Gold phi...@pobox.com wrote:
  From what I've read, all US highways in California should get similar
  treatment, in that they're signed with different shields than the standard
  ones.  Are there other regional sign variants for broader road networks in
  the US (or elsewhere)?
 
 Some US highways (segments of US 75A for sure) and many state highways
 feature generic white circle state route signage, though it's not clear to
 me if this was deliberate or a case of sign shop error, or older signs not
 yet replaced, respectively.

I think I'd prefer to ignore unusual or one-off sign variations like
those.  Let me put it this way: Are there any other places where a local
organization responsible for making and placing signs along a route has an
official policy of placing signs that differ significantly in appearance
from the signs used along the rest of the network?  US Business routes in
Maryland meet these criteria.  Where else is this true?

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
main(a){printf(a=main(a){printf(a=%c%s%c,34,a,34);},34,a,34);}
 --- --

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

Re: [Talk-us] Highway Shield Rendering

[Phil! Gold]

* Minh Nguyen m...@1ec5.org [2012-04-12 00:09 -0700]:
 Thanks for your attention to detail!

You're welcome.  :)

 By the way, four-digit circle shields appear to have broken over the
 last day or two.

Indeed they were.  It should be fixed now, pending a rerender.  (A few
days ago, I changed the shield generating mechanism from pregenerating
every shield and every known cluster (in every possible orientation) and
saving them in directories--to only pregenerating every individual shield
(which is still almost 45,000 images), storing them in the database, and
letting the database generate the clusters on demand.  With the old
system, we'd been cheating a little with the circle- and lozenge-style
shields by generating two sets of images (one with circles for all numbers
from 1 to , and one with circles for 1 to 99 and lozenges for 100 to
) and then symlinking states to those as appropriate.  With the new
setup, we have to generate all the shields for each state individually and
I just didn't go high enough for Kentucky.  I've now generated shields for
Kentucky up to 3999, which should cover everything I see in the database.
Wikipedia lists 9006 and 9008, but it looks like those are unsigned
reference numbers for some of the parkways.)

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
You know you're really somebody in the software world when Richard
Stallman complains about you having a gratuitous patent
   -- Source unknown
 --- --

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

Re: [Talk-us] Highway Shield Rendering

[Phil! Gold]

* James Mast rickmastfa...@hotmail.com [2012-04-12 09:40 -0400]:
 You need to create shields up to at least in the 6000 range for
 Kentucky.  The reason I'm saying this is that the have a 6000 series for
 small service roads.
[snip]
 So, on the safe side for the KY routes, I would create shields up to at
 least 6299 so that when people get around to properly tagging the 6000
 series, they will be rendered when necessary.

Are there any roads in the 4000s or 5000s?  If not, I can skip those and
just do the range from 6000 to 6299.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
I think...  I think it's in my basement... Let me go upstairs and check.
   -- Escher
 --- --

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

Re: [Talk-us] Highway Shield Rendering

[Phil! Gold]

* Minh Nguyen m...@1ec5.org [2012-04-12 10:06 -0700]:
 There's an ALT I-75 that needs its own sequence file

I had no idea there were alternate Interstates.  I added it under
network=US:I:Alternate, ref=75.  (Right now, it's rendering as regular
I-75.)

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
Hydrogen is a colorless, odorless gas which, given enough time, turns into
people.
   -- Henry Hiebert
 --- --

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

Re: [Talk-us] Network tag Re: Highway Shield Rendering

[Phil! Gold]

* Craig Hinners cr...@hinnerspace.com [2012-04-08 07:07 -0700]:
 Phil! Gold phi...@pobox.com:
  It seems to me that network=US:US:Business:MD is the logical extension of
  a scheme that has US:US and US:US:Business.
 
 My initial reaction is that this goes too far in mixing geographic,
 classification, and rendering concepts, which has a bad smell

I plan on experimenting with basing some rendering decisions on the is_in
tag, which should work for Maryland's US business routes (assuming it
works at all; is_in values aren't really standardized).

From what I've read, all US highways in California should get similar
treatment, in that they're signed with different shields than the standard
ones.  Are there other regional sign variants for broader road networks in
the US (or elsewhere)?

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
Research is to see what everybody else has seen, and to think what nobody
else has thought.
   -- Albert Szent-Gyoergi
 --- --

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

Re: [Talk-us] Highway Shield Rendering

[Phil! Gold]

* Phil! Gold phi...@pobox.com [2012-04-03 17:27 -0400]:
 Okay.  If there aren't any strenuous objections from other Virginians on
 the list, I'll go with US:VA:Secondary for the secondary routes and won't
 render them if they're tagged US:VA.

I've made this change.  It'll take a little while for everything to
rerender.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
  Who do you think you are, Zaphod Beebelbrox?
  Count the heads.
 --- --

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

Re: [Talk-us] Highway Shield Rendering

[Phil! Gold]

* Minh Nguyen m...@1ec5.org [2012-04-04 11:54 -0700]:
 More requests: in addition to its circular-shield state highway system,
 Kentucky also has an ad-hoc parkway network. At least some of them are
 tagged `network=US:KY:Parkway` with a shield URL in `symbol`.

Since I've now got shields rendering larger at higher zoom levels, I made
some shields for the Kentucky Parkways.  They are indeed pretty unreadable
until you get to about z17, but at that point you can mostly make out what
they are (or you can also just read the name on the road...).  At least
there's something on the motorways so they don't just look naked.

We're putting the shield images in the public domain (well, we're putting
them under a CC0 waiver, which amounts to the same thing semantically), so
I don't think the Kentucky Unbridled image would be compatible with
that.  I just went with an italic font.  (It's not like you can tell at
these resolutions, anyway.)

 One way to simplify them would be to use the routes' two-letter
 abbreviations.

NE2 suggested this for New York's parkways, too.  I want to see how the
current shields are received now that you can zoom in and see more detail
on them, but using the routes' initials is certainly a possibility if no
one likes their current incarnation.

 Adding to the mess, the AA Highway is a special case that I *think*
 belongs in `network=US:KY` as `ref=AA`.

I've added that, too.  The network=US:KY, ref=AA relation does not appear
to include all of the ways with the name AA Highway (it looks like the
relation ends somewhere around KY 2828).

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
The greatest obstacle to discovery is not ignorance, but the illusion of
knowledge.
   -- Daniel Boorstin
 --- --

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

Re: [Talk-us] Highway Shield Rendering

[Phil! Gold]

* Nathan Edgars II nerou...@gmail.com [2012-04-09 17:40 -0400]:
 Is there a reason there are no shields or fallback ovals here on
 Nocatee Parkway?
 http://elrond.aperiodic.net/shields/?zoom=15lat=30.12344lon=-81.39063layers=B0
 The way is tagged ref=CR 210 and the relation is
 network=US:FL:CR:St. Johns ref=210.

The short answer is that it appears to be a rendering bug.  The happy
response is that I just finished a reworking of the shield image
generation process[0] which appears to have fixed that bug as a side
effect.

County shield support is still pending[1], so it just gets the fallback
shields for now.


[0] The main benefit is that shield clusters are now generated on demand,
rather than in a separate batch process.  This should help keep the
rendered map more up to date.

[1] Including New Jersey county routes.  I took them out because they
didn't really fit into the code reworking I did.  They'll return when
I get the general-purpose county shield rendering working.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
Your pet monster should be kept in a secure cage from which it cannot
escape and into which you cannot accidentally stumble.
   -- Evil Overlord's Handbook, entry 28
 --- --

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

Re: [Talk-us] Highway Shield Rendering

[Phil! Gold]

* Nathan Edgars II nerou...@gmail.com [2012-04-04 22:26 -0400]:
 On 4/4/2012 10:23 PM, Nathan Edgars II wrote:
 There seems to be a problem here with US 17-92:
 http://elrond.aperiodic.net/shields/?zoom=12lat=28.96029lon=-81.31906layers=B0
 Change over to sign style and a bunch of shields appear.
 
 Er - upon rerendering, they don't appear in sign style anymore.
 That definitely says there's a problem now.

I appear to have inadvertantly broken the rendering of shield clusters
with one of my code changes last night.  (One of the deawbacks of having
the only public version of this also being my development environment.)
It's fixed now[0], and I've scheduled that area for rerendering.  I'll see
if I can tell which other areas were rendered during the bad window and
get them rerendered.

[0] It's fixed with the cutout shields.  Because of some changes I'm
working on, I don't have the source images to fix the sign style at
the moment, so it'll take me a little while to regenerate them.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
Only one human captain has ever survived battle with a Minbari fleet.  He
is behind me.  You are in front of me.  If you value your lives, be
somewhere else.
   -- Delenn (Babylon 5, Severed Dreams)
 --- --

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

Re: [Talk-us] Highway Shield Rendering

[Phil! Gold]

* Minh Nguyen m...@1ec5.org [2012-04-04 11:54 -0700]:
 More requests: in addition to its circular-shield state highway
 system, Kentucky also has an ad-hoc parkway network. [1] At least
 some of them are tagged `network=US:KY:Parkway` with a shield URL in
 `symbol`.

The Kentucky Parkways are on our TODO list.  I put them off initially
because not all of them have public domain SVGs on Wikipedia, so we'll
have to find appropriate reference images and make our own.

 Unfortunately, Kentucky has made these highways' shield designs more
 and more intricate over the years, most recently for the state's
 Unbridled Spirit tourism campaign, to the point that they're more
 appropriate as entire guide signs than shields. I know you prefer to
 keep true to the official signage, but the various shields are
 simply illegible at the current size.

So I see.  The old signs looked different enough that if you knew them
you'd probably be able to tell them apart even if you couldn't read the
tiny text.  The new ones look like they're too similar for that.

New York's parkways have a similar problem with legibility.  One of my
plans for dealing with them is to use larger shield images at high zoom
levels.  Kentucky's parkways would probably benefit from this approach as
well.

 Adding to the mess, the AA Highway is a special case that I *think*
 belongs in `network=US:KY` as `ref=AA`. It'd be nice to get that shield
 on the map, too.

I've made a note of that in the TODO.  It won't render until we make
images for its and the other parkways' shields.

 Finally, I just added `network=US:OH` and `symbol` to the Ohio
 Turnpike, à la Pennsylvania.

And there it is:
http://elrond.aperiodic.net/shields/?zoom=13lat=40.92904lon=-80.56185layers=B0

(It wasn't rendering before because the cluster script hadn't created a
cluster for it yet.  I forced that through.)  There's no shield for I-76
because it's tagged as ref=I 76.

Also, the rendering doesn't use the symbol URL.  It's not bad to tag it,
of course, since it's potentially useful information, but it won't affect
our rendering one way or another.

 Looks like the Indiana Toll Road has no relation yet.

That's fine.  We don't have a shield for it yet either.  :)

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
  What can you tell me about Dracula?
  Dracula?  Poncy bugger owes me £11, for one thing.
   -- Riley and Spike (Buffy the Vampire Slayer,
  Buffy vs. Dracula)
 --- --

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

Re: [Talk-us] Network tag Re: Highway Shield Rendering

[Phil! Gold]

* Paul Johnson ba...@ursamundi.org [2012-04-04 14:01 -0700]:
 OK, I'll bite.  How is putting banners in the network tag
 preferential?  why not something like...
 
 network=US:TX:FM
 modifier=Business
 
 network=US:US
 modifier=Business
 is_in=Maryland

Each of the potential tagging schemes had drawbacks.  One of the chief
drawbacks of this one is that a naive data consumer that looks at the
network and ref tags but not the modifier tag will get drastically
incorrect results.  (If it looks only at the network tag, then that's
useful information on its own.  If it looks only at the ref tag, it's not
that useful, but it's also not likely to come to incorrect conclusions
about the data.)

For the record, the drawbacks of the other approaches are:

 * network=US:US, ref=50 Business
   Mingles base reference numbers and route modifiers together in a way
   that's difficult or at least annoying for data consumers to process.
   Addressing this problem was one reason for separating the network and
   ref tags on route relations in the first place.

 * network=US:US:Business, ref=50
   Separates mainline routes from their alternates and variants, even
   though all of them are, outside of OSM, in the same road network.
   Complicates things for data consumers who care about the main network
   but not whether a route is a mainline or variant (not that there are
   any such consumers that I know of, but it would be a problem for
   them).

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
Signal_11 I'm trying to grow sentient molds to karma whore on slashdot.
   -- seen on #kuro5hin
 --- --

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

Re: [Talk-us] Highway Shield Rendering

[Phil! Gold]

* Phil! Gold phi...@pobox.com [2012-04-05 08:14 -0400]:
 * Minh Nguyen m...@1ec5.org [2012-04-04 11:54 -0700]:
  Looks like the Indiana Toll Road has no relation yet.
 
 That's fine.  We don't have a shield for it yet either.  :)

Ah.  And that's because my visit to Wikipedia left me unsure what the
current design for the Toll Road's shield was.  Any pointers would be
appreciated.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
joeyo msg nickserv identify m0rd0r
joeyo doh!
* SignOff joyeo: #kuro5hin (Killed (NickServ (GHOST command used by
 Dolgan)))
   -- seen on #kuro5hin
 --- --

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

Re: [Talk-us] Highway Shield Rendering

[Phil! Gold]

* Richard Weait rich...@weait.com [2012-04-04 01:09 -0400]:
 On Wed, Apr 4, 2012 at 12:33 AM, Phil! Gold phi...@pobox.com wrote:
  * Chris Lawrence lordsu...@gmail.com [2012-04-03 10:21 -0400]:
  http://elrond.aperiodic.net/shields/?zoom=14lat=37.13887lon=-80.34525layers=B0
  http://elrond.aperiodic.net/shields/?zoom=14lat=37.19653lon=-80.22878layers=B0
 
  Try those URLs again
 
 Wow.  Vertical pairs.  Looks nice, and switches back to horizontal as
 the line orientation changes.  :-)

I stayed up way too late last night.  Try visiting those URLs again.
(Once again, most of the map will rerender after you've looked at it so
the way to see the changes in different areas is to look at them once then
come back as much as a half hour later.)  Other places that I know are
rerendered include these:
http://elrond.aperiodic.net/shields/?zoom=14lat=37.27562lon=-79.93635layers=B0
http://elrond.aperiodic.net/shields/?zoom=13lat=40.12983lon=-74.71446layers=B0

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
ps axh -o%p | xargs perl -e '`kill -9 $ARGV[rand @ARGV]`'
 --- --

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

Re: [Talk-us] Highway Shield Rendering

[Phil! Gold]

* Nathan Edgars II nerou...@gmail.com [2012-04-04 10:41 -0400]:
 On 4/2/2012 11:35 AM, Phil! Gold wrote:
 For things like Florida's toll roads, we currently treat that as a
 separate network, so a route relation tagged as network=US:FL:Toll,
 ref=528 would get the toll shield.
 
 I've done this: http://www.openstreetmap.org/browse/changeset/11177509

The server's a bit overloaded at the moment, so already-rendered tiles
might take a while to rerender and show the shields, but new renderings of
not-yet-present tiles are given priority, so I was able to get some fresh
tiles at zoom 15:
http://elrond.aperiodic.net/shields/?zoom=15lat=28.4117lon=-80.82026layers=B0

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
He won't be able to summon a demon THAT quick...
   -- Famous Last Words, #879
 --- --

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

Re: [Talk-us] Highway Shield Rendering

[Phil! Gold]

* Josh Doe j...@joshdoe.com [2012-04-04 08:55 -0400]:
 Is this something that could be used in a Carto stylesheet, or does it
 use special syntax only supported by XML?

I'm not sure, because I don't really know Carto.  Most of the magic comes
from two places: first, there are PostgreSQL functions that take a way ID
and return a string that gives the path to the shield for that way;
second, there's the path expression syntax added to Mapnik2 that lets you
use database fields in image filenames.  If you can represent both of
those in Carto, you don't need to touch an XML stylesheet.

Just for reference, here's a relevant extract from the XML we're using:

Style name=roads-text-ref
Rule
Filter[highway] = 'motorway' and [route_shield] lt;gt; 
''/Filter
maxscale_zoom13;
minscale_zoom18;
ShieldSymbolizer file=shields;/[route_shield].png 
minimum-distance=30 no-text=true placement=line spacing=640 
fontset-name=book-fonts size=10 fill=whitenull/ShieldSymbolizer
/Rule
!-- ... --
/Style
Layer name=roads-text-ref status=on srs=osm2pgsql_projection;
StyleNameroads-text-ref/StyleName
Datasource
Parameter name=table
(SELECT way, highway, aeroway, ref, char_length(ref) as length,
CASE WHEN bridge IN ('yes','true','1') THEN 'yes'::text
 ELSE bridge END AS bridge,
route_shield(osm_id) route_shield
   FROM prefix;_line
   WHERE (highway IS NOT NULL OR aeroway IS NOT NULL)
 AND ((ref IS NOT NULL AND char_length(ref) BETWEEN 1 AND 
8) OR
  route_refs(osm_id) IS NOT NULL)
) AS roads
/Parameter
datasource-settings;
/Datasource
/Layer

 I know it's not really relevant to this thread, but since you have a
 separate stylesheet from the standard OSM one, maybe you could reduce
 the prominence of standard highway labels on residential/unclassified
 highways:
 http://elrond.aperiodic.net/shields/?zoom=15lat=38.78332lon=-77.30564layers=B0
 https://trac.openstreetmap.org/ticket/4183

Ooof.  I'm trying to limit the stylesheet changes to just what's needed to
put our shields on properly, but I can probably tweak the font settings on
those a little.  They do kind of need it.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
Like the ski resort full of girls hunting for husbands and husbands
hunting for girls, the situation is not as symmetrical as it might seem.
   -- Alan MacKay
 --- --

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

Re: [Talk-us] Network tag Re: Highway Shield Rendering

[Phil! Gold]

* Nathan Edgars II nerou...@gmail.com [2012-04-04 11:54 -0400]:
 It seems that many people see the network tag as not representing a
 network but a shield design. Does this sound accurate?

That matches my sense of what people have said about the tagging.  I've
been thinking of them in terms of subsets of a larger network, but since
the subset is largely determined by how it's signed, it amounts to the
same thing.


* Craig Hinners cr...@hinnerspace.com [2012-04-04 09:14 -0700]:
 One of many examples: Maryland uses a unique green-on-white shield for
 US Business routes, but those roads still get tagged as
 network=US:US:Business, not network=US:US:Business:MD or somesuch.

It seems to me that network=US:US:Business:MD is the logical extension of
a scheme that has US:US and US:US:Business.  I had actually planned on
attaching Maryland's US Business shields to the US:US:Business:MD network
once I made them, but I haven't gotten to those yet.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
vees my htaccess ban finger is twitching
   -- seen on #umbclinux
 --- --

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

Re: [Talk-us] Highway Shield Rendering

[Phil! Gold]

* Nathan Edgars II nerou...@gmail.com [2012-04-04 11:51 -0400]:
 (By the way, if it wasn't clear, you've done some good work here.)

Thank you.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
There's a frood who really knows where his towel is.

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

Re: [Talk-us] Highway Shield Rendering

[Phil! Gold]

* CrystalWalrein closed...@hotmail.com [2012-04-02 15:45 -0700]:
 For areas in New Jersey, when I look at this rendering, I get county shields
 for all 500-series roads, but no shields are shown for 600-series roads
 anywhere. 
 
 The formatting for county route relations in New Jersey is
 'network=US:NJ:[county name]' for all county routes that are not part of
 the statewide system (for which 'network=US:NJ:CR' is used).

This is a known problem and more or less falls under we're not really
doing county roads yet.  We render the pentagon for routes with the
network US:NJ:CR, but there's no rendering yet for US:NJ:county.  That's
partly because I haven't sorted through the counties to separate out the
ones that don't use the blue pentagon, and partly because handling a lot
of differently-named but having-very-similar-shields networks would be
kind of a pain with our current setup, so I need to write some more code
to help with that.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
I think...  I think it's in my basement... Let me go upstairs and check.
   -- Escher
 --- --

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