On 02/06/2011 03:38 PM, Scott Rollins wrote:
> I don't have the technical knowledge background to helpfully contribute
> to the decisions on how things ought to be done. It's been nearly five
> years since I dipped my toes into editing the map (and providing GPS
> traces, before I lived in the US)
On Sun, Feb 6, 2011 at 4:38 PM, Scott Rollins wrote:
> Having read a few days worth of this thread, THIS THREAD exemplifies why I
> am not an active contributor to this project. It is way too difficult to
> figure out "the right way" to enter information. Then, having entered the
> information "th
Having read a few days worth of this thread, THIS THREAD exemplifies why I
am not an active contributor to this project. It is way too difficult to
figure out "the right way" to enter information. Then, having entered the
information "the right way," there may or may not be an easy way to see that
On 2/6/2011 2:41 PM, Paul Johnson wrote:
> On 02/06/2011 05:14 AM, Nathan Edgars II wrote:
>
>> What does this have to do with anything?
>
> USDOT is working hard to make all federal highways bicycle accessible.
> These routes are national in nature and often share with the motorway
> where bicycl
On 02/06/2011 05:14 AM, Nathan Edgars II wrote:
> What does this have to do with anything?
USDOT is working hard to make all federal highways bicycle accessible.
These routes are national in nature and often share with the motorway
where bicycles are permitted, or have a third roadway specificall
On 2/5/2011 10:44 PM, Paul Johnson wrote:
> On 02/04/2011 01:42 AM, Nathan Edgars II wrote:
>> On 2/3/2011 11:15 PM, Paul Johnson wrote:
>>> underlying ways
>>> often have refs that belong to them (like bridge numbers) but not the
>>> route itself.
>> You've said this a number of times without exp
with a single way, as
opposed to multiple routes.
---Original Email---
Subject :Re: [Talk-us] Relations, cycle routes, shapefiles
>From :mailto:ba...@ursamundi.org
Date :Sat Feb 05 21:44:10 America/Chicago 2011
On 02/04/2011 01:42 AM, Nathan Edgars II wrote:
> On 2/3/2011 11:15 PM
On 02/05/2011 05:09 PM, Nathan Edgars II wrote:
> On 2/5/2011 12:36 PM, stevea wrote:
>> Take a look at Santa Cruz County, California with OSM Cycle Map layer
>> (see the text in the last paragraph at
>> http://wiki.openstreetmap.org/wiki/Santa_Cruz_County,_California#Work_to_be_done_in_the_County)
On 02/04/2011 11:36 PM, Peter Budny wrote:
> I'm sorry that you don't seem to see the value in using relations.
>
> You are definitely correct... there are many ways to represent the same
> set of data, with no loss of integrity. Computer programmers often have
> to make choices over how complex
On 02/04/2011 10:53 PM, Craig Hinners wrote:
> There is no technical reason why direct application of tags to ways
> can't work.
Unless you're considering routes with multiple references involving
different modes. What works for cyclists doesn't work for transit users
or motorists, and any vice-
On 02/05/2011 09:14 AM, Craig Hinners wrote:
> Sure, relations get you an additional degree of normalization. And using
> relations to carry route/network tags gets the job done, granted. But at
> what cost?
>
> I've yet to hear a convincing argument that justifies the additional
> complexity of r
On 02/04/2011 01:42 AM, Nathan Edgars II wrote:
> On 2/3/2011 11:15 PM, Paul Johnson wrote:
>> underlying ways
>> often have refs that belong to them (like bridge numbers) but not the
>> route itself.
> You've said this a number of times without explanation. Why does the
> bridge number, or ODOT's
On 02/04/2011 01:44 AM, Nathan Edgars II wrote:
> On 2/3/2011 11:20 PM, Paul Johnson wrote:
>> If it's a bicycle boulevard, it should have it's own LCN relation (even
>> if it does have one member), as it would also qualify as a route. And
>> the way will probably be split up many times over it's
Using semicolons brings us back to "impossible to query without string
manipulation".
I agree with you that multiple values per key would have been a better design
for many things, it still wouldn't solve the fact that there may be a set of
keys (e.g. names) associated with each ref rather than
>[The "rich key" methodology] still can't handle ways that are part of more than one route (e.g. situations like the I-580, I-80 overlap are actually fairly common).It can, using semicolon-delimited values. Your example becomes:highway:network:us:interstate=580;80As an aside, if OSM didn't have the
On 2/5/2011 12:36 PM, stevea wrote:
Take a look at Santa Cruz County, California with OSM Cycle Map layer
(see the text in the last paragraph at
http://wiki.openstreetmap.org/wiki/Santa_Cruz_County,_California#Work_to_be_done_in_the_County).
We tag highways (AGAIN: additionally tag the WAY contai
On 02/03/2011 02:25 PM, PJ Houser wrote:
Hi all,
I have some basic questions:
> 1) Why are relations preferred for bike routes?
Take a look at Santa Cruz County, California with
OSM Cycle Map layer (see the text in the last
paragraph at
http://wiki.openstreetmap.org/wiki/Santa_Cruz_Cou
On Feb 5, 2011, at 7:14 AM, Craig Hinners wrote:
> Sure, relations get you an additional degree of normalization. And using
> relations to carry route/network tags gets the job done, granted. But at what
> cost?
>
> I've yet to hear a convincing argument that justifies the additional
> comple
"Craig Hinners" writes:
> Want to render the Oregon cycleway shield? Do so if the
> tag.key==cycleway:oregon and put the tag.value in the shield.
It was as if millions of programmers cried out in horror, and were then
silenced...
This is the problem with keys... it quickly adds lots of special-
Sure, relations get you an additional degree of normalization. And using relations to carry route/network tags gets the job done, granted. But at what cost?I've yet to hear a convincing argument that justifies the additional complexity of relations as they are being championed as carriers of route/
What are you going to do when the route is part of more than one state highway
or bike route? You can't do a db query for ref:highway:ca:0, ref:highway:ca:1,
ref:highway:ca:n without doing expensive string comparisons, and you can't
explode a delimited list of refs without breaking the one key =
I'm sorry that you don't seem to see the value in using relations.
You are definitely correct... there are many ways to represent the same
set of data, with no loss of integrity. Computer programmers often have
to make choices over how complex the data model should be. Some very
large and effici
The only thing that relations add (in terms of tagging) is an order of magnitude of complexity.There is no technical reason why direct application of tags to ways can't work. However, this requires the use of highly-specific tag keys, such as a unique key for interstate highways, a unique key for U
On 2/3/2011 11:20 PM, Paul Johnson wrote:
If it's a bicycle boulevard, it should have it's own LCN relation (even
if it does have one member), as it would also qualify as a route. And
the way will probably be split up many times over it's existence as turn
restrictions get added, ways get split
On 2/3/2011 11:15 PM, Paul Johnson wrote:
underlying ways
often have refs that belong to them (like bridge numbers) but not the
route itself.
You've said this a number of times without explanation. Why does the
bridge number, or ODOT's internal referencing, "belong" to the way,
while the route
On 2/3/2011 6:37 PM, j...@jfeldredge.com wrote:
I know that, using relations, a particular way can be part of several different
routes. Is this also true if the ways are used directly, instead of through a
relation?
Yes, using semicolons: lcn_ref=1;8
On 2/3/2011 3:25 PM, PJ Houser wrote:
Hi all,
I have some basic questions:
1) Why are relations preferred for bike routes?
If there's a continuous route from point A to point B, it's easier to
keep track of it as a relation. If there's just a signed network using
"bike route" signs, there's n
On 02/03/2011 05:27 PM, Dave Hansen wrote:
> On Thu, 2011-02-03 at 12:25 -0800, PJ Houser wrote:
>> I have some basic questions:
>>
>> 1) Why are relations preferred for bike routes?
>
> Think of it like US highways, say US26 in Portland. 26 is at times a
> motorway, but it's also carried on Clay
On 02/03/2011 02:25 PM, PJ Houser wrote:
> Hi all,
>
> I have some basic questions:
>
> 1) Why are relations preferred for bike routes?
Relations are preferred for /all/ routes, actually. This is because the
attributes of said route span unique ways. For example, only parts of
Marine Drive in
I know that, using relations, a particular way can be part of several different
routes. Is this also true if the ways are used directly, instead of through a
relation?
---Original Email---
Subject :Re: [Talk-us] Relations, cycle routes, shapefiles
>From :mailto:d...@sr71.net
D
On Thu, 2011-02-03 at 12:25 -0800, PJ Houser wrote:
> I have some basic questions:
>
> 1) Why are relations preferred for bike routes?
Think of it like US highways, say US26 in Portland. 26 is at times a
motorway, but it's also carried on Clay Street downtown and Powell Blvd
on the east side. T
Hi,
PJ Houser wrote:
1) Why are relations preferred for bike routes?
Because a stretch of way can belong to different routes at the same
time, and this is difficult to model without relations.
2) In the database, how do relations apply to ways? The attributes
associated with a relation - h
Hi all,
I have some basic questions:
1) Why are relations preferred for bike routes?
2) In the database, how do relations apply to ways? The attributes
associated with a relation - how are they tied to ways? Will routing
software use the attributes in a relation to determine if a way is suitable?
33 matches
Mail list logo
