Greg Troxel wrote:
Paul Johnson ba...@ursamundi.org writes:
Why make this more complicated than it has to be? Leave the names on
the underlying way, not the relations; leave the refs on the relations,
not the underlying ways. Then it's a matter of fixing mapnik and t...@h to
do the right
On Sun, 12 Apr 2009 22:58:22 -0700
Paul Johnson ba...@ursamundi.org wrote:
Well, in some cases, because due to historical factors, some highways
have the same name despite having radically different route
references, and the names don't apply to the whole relation, but
members of the relation.
Richard Weait rich...@weait.com writes:
On Sun, 2009-04-12 at 16:55 -0700, Paul Johnson wrote:
Apollinaris Schoell wrote:
It contains all you need to pick the correct sign. But you need the
whole knowledge about signs for all states, county ...
as an example California uses different
On Mon, Apr 13, 2009 at 8:28 AM, Greg Troxel g...@ir.bbn.com wrote:
The US highways in California are really (I think) regular US highways,
but CA uses a different kind of sign. So tagging then us_us_ca seems
again like tagging for the renderer. This is sort of OK, perhaps, but
it bothers me
Sorry to be slow to the conversation. I have been importing the NHD
data for Georgia, and have scripts that do the conversion for all of the
NHD Ftypes that I have found so far. I have also prepared a version of
polyshp2osm that converts areas to complex multipolygons, which allows a
On Mon, Apr 13, 2009 at 8:14 AM, Theodore Book tb...@libero.it wrote:
Sorry to be slow to the conversation. I have been importing the NHD
data for Georgia, and have scripts that do the conversion for all of the
NHD Ftypes that I have found so far. I have also prepared a version of
I have just gained access (and permission to import) some very good (and
current) landuse data for the Metro Atlanta area. However, before, I do
so, I need to remove / delete the data from the previous statewide
landuse import for the relevant counties. It should be technically
simple:
On 13 Apr 2009, at 5:36 , Adam Schreiber wrote:
What about:
addr:country=us
addr:state=ca
network=us
or
addr:country=us
addr:state=ca
network=i
network should be US, I,
all signs use uppercase, there can be so many uses for the data.
network should reflect the real usage
I'm in danger of spending more time flaming than fixing the map, but
have always been interested in the database schema aspect of OSM.
Evolving tags is messier than a designed scheme, but I see the
wisdom of
how it avoids the wrong design persisting. Still, I think it may make
sense to
The lower case has nothing to do with a renderer, just OSM convention
for key value pairs other than name.
network name is an officially documented and commonly used name. it
should be treated like the name tag or the ref tag.
how else could a renderer come up with the correct use if
Why make this more complicated than it has to be? Leave the names on
the underlying way, not the relations; leave the refs on the
relations,
not the underlying ways. Then it's a matter of fixing mapnik and
t...@h to
do the right thing, since relations are set up better to handle
On Mon, Apr 13, 2009 at 3:57 PM, Alex Mauer ha...@hawkesnest.net wrote:
what is the best solution for another problem I have seen.
navigation systems should use the name/ref on the signs. the names are
never (rarely?) used for interstate and us routes. but commonly used
for county routes (
On 13 Apr 2009, at 11:06 , Zeke Farwell wrote:
Joseph Jon Booker said:
My approach (and I don't know if you'll agree with this) is to
considerPacific Highway something independent of I-5 or Oregon 99.
Pacific Highway is more like its own designation for a highway, and
ways which
13 matches
Mail list logo
