Re: [Talk-us] Trunk

[Bradley White]

If we can determine importance (which is what the 'highway=' tag
fundamentally represents per the wiki) solely by what's on the ground,
why not just tag what's physically there, ditch the 'highway' tag
altogether, and let the renders handle it with their own algorithms?

>On Sun, Oct 15, 2017 at 12:19 AM, Paul Johnson  wrote:
>>
>> The US is pretty well known for overbuilding highways.  Are we trying to
>> document how things are on the ground or how things are actually
>> connected?  If we're going for the former, then yeah, only Bend Parkway and
>> a brief streak through Klamath Falls is a trunk part of US 97.  If we're
>> going for the latter, then go ahead with NE2's idea and smash almost
>> everything into trunk.
>>
>
>
>Keep hitting send too soon.  Personally, I find what's on the ground to be
>more useful than the connections.  Game theory and any routing engine can
>figure out the connections.  But knowing what's a stupid rural road with an
>overly generous speed limit and what's almost but not quite a freeway is
>more useful.  If I'm driving a big rig going from southwestern Canada or
>Alaska to somewhere in Nevada, I don't give two shakes what some toolbag
>things is the most prominent road.  I care more about what *actually is a
>big road*.  Calling a two leg segment of US 97 30km outside of East
>Butthump, Oregon a trunk is a great disservice when it's basically on par
>with County Road Number Who Even Cares tracing off to Outer
>Smalltownsville, other than the fact that it goes through.  Calling it a
>trunk when it's not is going to set an unreasonably high expectation for
>what is otherwise an overtravelled, glorified two digit National Forest
>route through the east Cascades frontier.  Primary is definitely ample for
>that road, even if you're going a more obscure minor haul route like Salem
>to Reno.

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

Re: [OSM-talk-be] mapping ALPR cameras (in Ghent)

[Marc Gemis]

Wit respect to the "to-node", IMHO any node on the way that shows the
driving direction that is controlled is fine. So if the way to which
you want the add the enforcement relation is drawn from left to
right., any node right of the from node is fine. For a way drawn right
to left, any node to the left of the from node is OK.


regards

m

On Fri, Oct 13, 2017 at 1:39 PM, Santens Seppe  wrote:
> Hi all,
>
>
>
> I was triggered by a tweet from a journalist
> (https://twitter.com/bertstaes/status/918017848844476416) to start mapping
> ALPR cameras in Ghent that control access to the “car free area”. Could you
> have a look at one example I tried to work out? All advice is welcome.
>
>
>
> http://www.openstreetmap.org/node/5160676344
>
>
>
> Some questions:
>
> ·Can this camera used for access enforcement be seen as a
> surveillance camera? In other words, is it ok to use man_made=surveillance
> for this?
>
> ·I added an enforcement relation with this camera as “device”. I put
> the node where the traffic sign is as “from”, but I don’t see which node I
> should put as “to”. Can I just choose the next node on this way (that would
> be http://www.openstreetmap.org/node/201250401). It seems ok to me, but also
> a bit arbitrary…
>
>
>
> Other suggestions?
>
>
>
> Seppe
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [Talk-us] Trunk

[Paul Johnson]

On Sun, Oct 15, 2017 at 12:19 AM, Paul Johnson  wrote:
>
> The US is pretty well known for overbuilding highways.  Are we trying to
> document how things are on the ground or how things are actually
> connected?  If we're going for the former, then yeah, only Bend Parkway and
> a brief streak through Klamath Falls is a trunk part of US 97.  If we're
> going for the latter, then go ahead with NE2's idea and smash almost
> everything into trunk.
>


Keep hitting send too soon.  Personally, I find what's on the ground to be
more useful than the connections.  Game theory and any routing engine can
figure out the connections.  But knowing what's a stupid rural road with an
overly generous speed limit and what's almost but not quite a freeway is
more useful.  If I'm driving a big rig going from southwestern Canada or
Alaska to somewhere in Nevada, I don't give two shakes what some toolbag
things is the most prominent road.  I care more about what *actually is a
big road*.  Calling a two leg segment of US 97 30km outside of East
Butthump, Oregon a trunk is a great disservice when it's basically on par
with County Road Number Who Even Cares tracing off to Outer
Smalltownsville, other than the fact that it goes through.  Calling it a
trunk when it's not is going to set an unreasonably high expectation for
what is otherwise an overtravelled, glorified two digit National Forest
route through the east Cascades frontier.  Primary is definitely ample for
that road, even if you're going a more obscure minor haul route like Salem
to Reno.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Evin Fairchild]

You clearly haven't driven on US 97. It's a fairly busy road with a good
amount of truck traffic and lots of little towns along it. That was my
experience when I drove it. It goes thru central Oregon, which is arid, but
not totally desolate. There was PLENTY of cars going in the other
direction. We drove it between OR 138 and OR 58, and drove back to Eugene
via OR 58, another road that had LOTS of truck traffic, and IMO is fairly
analogous in terms of traffic to US 2 over Stevens Pass.

On Sat, Oct 14, 2017 at 9:47 PM, Paul Johnson  wrote:

> On Sat, Oct 14, 2017 at 11:23 PM, Nathan Mills  wrote:
>
>> I guess my question is why primary isn't good enough for the primary
>> route between places that don't have higher grade roads connecting them?
>> These important mostly two lane roads are perfectly fine as primary.
>>
>
> Funding, mostly.  I'd consider Bend Parkway a trunk (the dual carriageway
> section between County Road 40 and US Route 20) But even then, the best
> Oregon's ever going to do with the rest of the US 97 route is a 2-lane
> single carriageway.  It's a desert road where you can go a decent amount of
> time without encountering anyone else in either direction, almost a road to
> go to of last resort if you're lost on foot as a last resort (and I realize
> most of the roads that cross it are posted "No bicycles, no pedestrians, no
> water available beyond this point", most of Oregon's open freaking desert
> with no features for dozens to hundreds of kilometers if terrain doesn't
> end the road far sooner).  That's totally a primary where it's not trunk.
>
>
>> In many cases primary routes happen to be divided, but in many cases they
>> aren't. Having a simple distinction between the two by using trunk to mean
>> non-motorway divided (or similar) preserves long-standing practice and
>> generally seems like a good thing to me.
>
>
>  Same here.  Bend Parkway's a solid trunk.  Milwaukie Expressway, too.
> Oklahoma City's Northwest Expressway's either a large primary or a bitty
> trunk; Tulsa's Riverside Parkway is a large primary.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Paul Johnson]

On Sat, Oct 14, 2017 at 11:42 PM, Ian Dees  wrote:

> Hi everyone,
>
> It sounds like this thread isn't really going anywhere. Since email
> threads like this tend to be a terrible way to have intense conversation, I
> would encourage you all to talk in real time on IRC, Slack, or a video chat
> of some sort. Maybe Martijn could set up a Hangout?
>

Maybe someone could set up a poll?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Paul Johnson]

On Sat, Oct 14, 2017 at 11:23 PM, Nathan Mills  wrote:

> I guess my question is why primary isn't good enough for the primary route
> between places that don't have higher grade roads connecting them? These
> important mostly two lane roads are perfectly fine as primary.
>

Funding, mostly.  I'd consider Bend Parkway a trunk (the dual carriageway
section between County Road 40 and US Route 20) But even then, the best
Oregon's ever going to do with the rest of the US 97 route is a 2-lane
single carriageway.  It's a desert road where you can go a decent amount of
time without encountering anyone else in either direction, almost a road to
go to of last resort if you're lost on foot as a last resort (and I realize
most of the roads that cross it are posted "No bicycles, no pedestrians, no
water available beyond this point", most of Oregon's open freaking desert
with no features for dozens to hundreds of kilometers if terrain doesn't
end the road far sooner).  That's totally a primary where it's not trunk.


> In many cases primary routes happen to be divided, but in many cases they
> aren't. Having a simple distinction between the two by using trunk to mean
> non-motorway divided (or similar) preserves long-standing practice and
> generally seems like a good thing to me.


 Same here.  Bend Parkway's a solid trunk.  Milwaukie Expressway, too.
Oklahoma City's Northwest Expressway's either a large primary or a bitty
trunk; Tulsa's Riverside Parkway is a large primary.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Ian Dees]

Hi everyone,

It sounds like this thread isn't really going anywhere. Since email threads
like this tend to be a terrible way to have intense conversation, I would
encourage you all to talk in real time on IRC, Slack, or a video chat of
some sort. Maybe Martijn could set up a Hangout?

-Ian

On Oct 5, 2017 17:33, "Martijn van Exel"  wrote:

> Question for you all:
>
> What make Michigan state routes 5 and 10[1] trunks rather than primaries?
>
> To my mind these are highway=primary mainly because of at-grade
> intersections.. I am still confused about what makes a trunk road in the
> US. To my mind it's roads with no at-grade intersections but not built to
> interstate standards / not having an interstate designation... I'm not
> looking to open up a can of worms but I would really like to understand.
>
> Martijn
>
> [1] https://www.openstreetmap.org/#map=13/42.5188/-83.3982
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Evin Fairchild]

I think primary ought to be used for major state routes and minor US
routes, secondary for minor state routes, and tertiary for collector
arterials.

On Oct 14, 2017 9:23 PM, "Nathan Mills"  wrote:

> I guess my question is why primary isn't good enough for the primary route
> between places that don't have higher grade roads connecting them? These
> important mostly two lane roads are perfectly fine as primary.
>
> In many cases primary routes happen to be divided, but in many cases they
> aren't. Having a simple distinction between the two by using trunk to mean
> non-motorway divided (or similar) preserves long-standing practice and
> generally seems like a good thing to me.
>
> -Nathan
>
> On October 14, 2017 11:18:43 PM EDT, Evin Fairchild 
> wrote:
>>
>> I'm amazed that NE2's definition hasn't been removed after 7 years. It
>> must not have been that controversial or else someone would have removed
>> it. Seems like you just don't agree with his opinion and just really have
>> some personal problems with that guy. I know he engaged in some really dumb
>> stuff like unilaterally changing all the US highways to trunk and he
>> ultimately got banned for a turn restriction dispute with you over a parclo
>> interchange in Florida, but he's not the only one who believes that many US
>> highways are deserving of trunk status given the amount of traffic they
>> receive and their importance in a region's highway network.
>>
>> On Sat, Oct 14, 2017 at 8:02 PM, Paul Johnson 
>> wrote:
>>
>>>
>>>
>>> On Sat, Oct 14, 2017 at 9:43 PM, Evin Fairchild 
>>> wrote:
>>>


 On Oct 14, 2017 5:41 PM, "Paul Johnson"  wrote:



 On Sat, Oct 14, 2017 at 7:28 PM, Evin Fairchild 
 wrote:

>
>
> On Oct 14, 2017 4:25 PM, "Paul Johnson"  wrote:
>
>
>
> On Sat, Oct 14, 2017 at 6:08 PM, Evin Fairchild 
> wrote:
>
>> On Oct 14, 2017 2:04 PM, "Wolfgang Zenker" 
>> wrote:
>>
>> Hi,
>>
>> it looks to me that this discussion is going in circles, not forward
>> at the moment. IMHO it does not make a lot of sense to argue what
>> might
>> be the true meaning of "trunk". Instead, we should concentrate on what
>> it should mean, document this meaning if we can agree on one and don't
>> worry to much about what other maps or different parts of the world
>> think a "trunk" is.
>>
>>
>> Yeah, the whole reason why this discussion hasn't resulted in a
>> consensus for 7+ years is because people have dug in their heels so much
>> and said "trunk roads can only be divided highways, no its, ands, or 
>> buts."
>> I support what is written on the wiki that says that it is the second 
>> most
>> important road after motorway. I haven't seen a single compelling reason 
>> to
>> believe that trunk should only apply to divided highways. You can still
>> tell whether a trunk is divided at low zooms based on how thick the line 
>> is.
>>
>
> I'm OK with single carriageway trunks, if they're controlled access,
> like, say, the Chickasaw Turnpike, and similarly constructed roads.  The
> single carriageway parts of US 395 or US 97 in eastern Oregon, US 400 in
> Kansas or US 75 in Oklahoma, though?  They're all solid primaries.
>
>
> You actually think that US 97, the main artery thru Central Oregon
> that passes thru the Bend area which has a 75K population and a metro
> population of 100K shouldn't be connected to the outside world with a 
> trunk
> road?
>

 Yes.  Because for the majority of that length that isn't between US 20
 and County Road 40 is, for all practical purposes, the same generic two
 lane, shoulderless ribbon of pavement that pretty much any two lane Texas
 FM or RM road, or pretty much any other similar road in the American west.
 Primary is more than ample for such a road.


 That's not accurate to compare a US highway to some podunk FM/RM road
 out in the middle of nowhere in Texas. US 97 has way more traffic and very
 deserving of its trunk road designation. Most US highways are, except in
 places where they parallel an interstate or other freeway. BTW, this is
 what is written on the wiki.

>>>
>>>  Which was updated by NE2 to skew towards his view of the situation.
>>> Any edits by him have negative value at this point.  Disconnect his reality
>>> from actual reality.
>>>
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Nathan Mills]

I guess my question is why primary isn't good enough for the primary route 
between places that don't have higher grade roads connecting them? These 
important mostly two lane roads are perfectly fine as primary.

In many cases primary routes happen to be divided, but in many cases they 
aren't. Having a simple distinction between the two by using trunk to mean 
non-motorway divided (or similar) preserves long-standing practice and 
generally seems like a good thing to me.

-Nathan

On October 14, 2017 11:18:43 PM EDT, Evin Fairchild  wrote:
>I'm amazed that NE2's definition hasn't been removed after 7 years. It
>must
>not have been that controversial or else someone would have removed it.
>Seems like you just don't agree with his opinion and just really have
>some
>personal problems with that guy. I know he engaged in some really dumb
>stuff like unilaterally changing all the US highways to trunk and he
>ultimately got banned for a turn restriction dispute with you over a
>parclo
>interchange in Florida, but he's not the only one who believes that
>many US
>highways are deserving of trunk status given the amount of traffic they
>receive and their importance in a region's highway network.
>
>On Sat, Oct 14, 2017 at 8:02 PM, Paul Johnson 
>wrote:
>
>>
>>
>> On Sat, Oct 14, 2017 at 9:43 PM, Evin Fairchild 
>> wrote:
>>
>>>
>>>
>>> On Oct 14, 2017 5:41 PM, "Paul Johnson"  wrote:
>>>
>>>
>>>
>>> On Sat, Oct 14, 2017 at 7:28 PM, Evin Fairchild
>
>>> wrote:
>>>


 On Oct 14, 2017 4:25 PM, "Paul Johnson" 
>wrote:



 On Sat, Oct 14, 2017 at 6:08 PM, Evin Fairchild
>
 wrote:

> On Oct 14, 2017 2:04 PM, "Wolfgang Zenker"
>
> wrote:
>
> Hi,
>
> it looks to me that this discussion is going in circles, not
>forward
> at the moment. IMHO it does not make a lot of sense to argue what
>might
> be the true meaning of "trunk". Instead, we should concentrate on
>what
> it should mean, document this meaning if we can agree on one and
>don't
> worry to much about what other maps or different parts of the
>world
> think a "trunk" is.
>
>
> Yeah, the whole reason why this discussion hasn't resulted in a
> consensus for 7+ years is because people have dug in their heels
>so much
> and said "trunk roads can only be divided highways, no its, ands,
>or buts."
> I support what is written on the wiki that says that it is the
>second most
> important road after motorway. I haven't seen a single compelling
>reason to
> believe that trunk should only apply to divided highways. You can
>still
> tell whether a trunk is divided at low zooms based on how thick
>the line is.
>

 I'm OK with single carriageway trunks, if they're controlled
>access,
 like, say, the Chickasaw Turnpike, and similarly constructed roads.
> The
 single carriageway parts of US 395 or US 97 in eastern Oregon, US
>400 in
 Kansas or US 75 in Oklahoma, though?  They're all solid primaries.


 You actually think that US 97, the main artery thru Central Oregon
>that
 passes thru the Bend area which has a 75K population and a metro
>population
 of 100K shouldn't be connected to the outside world with a trunk
>road?

>>>
>>> Yes.  Because for the majority of that length that isn't between US
>20
>>> and County Road 40 is, for all practical purposes, the same generic
>two
>>> lane, shoulderless ribbon of pavement that pretty much any two lane
>Texas
>>> FM or RM road, or pretty much any other similar road in the American
>west.
>>> Primary is more than ample for such a road.
>>>
>>>
>>> That's not accurate to compare a US highway to some podunk FM/RM
>road out
>>> in the middle of nowhere in Texas. US 97 has way more traffic and
>very
>>> deserving of its trunk road designation. Most US highways are,
>except in
>>> places where they parallel an interstate or other freeway. BTW, this
>is
>>> what is written on the wiki.
>>>
>>
>>  Which was updated by NE2 to skew towards his view of the situation. 
>Any
>> edits by him have negative value at this point.  Disconnect his
>reality
>> from actual reality.
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Paul Johnson]

On Sat, Oct 14, 2017 at 10:52 PM, Evin Fairchild 
wrote:

> That can be easily rectified by tagging trunk roads in accordance with the
> wiki.
>

Exactly backwards, since the wiki is supposed to document how things are
already consumed, not the other way around.  Which wasn't the other way
around since 2010 when NE2 gamed both the wiki and the map for himself.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Evin Fairchild]

That can be easily rectified by tagging trunk roads in accordance with the
wiki. They should be the most important non-motorway roads. Tagging most US
highways as such fulfills this.

On Sat, Oct 14, 2017 at 8:03 PM, Paul Johnson  wrote:

>
>
> On Sat, Oct 14, 2017 at 9:43 PM, Evin Fairchild 
> wrote:
>
>>
>>
>> On Oct 14, 2017 5:41 PM, "Paul Johnson"  wrote:
>>
>> Or, map it cleanly to limited access expressways and super2s.  I really
>> think people are trying to overthink this a bit; being a little less
>> subjective isn't necessarily a bad thing.
>>
>>
>> No, just no. I don't like looking at the US at a low zoom and seeing
>> disjointed bits of trunk that aren't connected to anything. Makes the US
>> map look bad.
>>
>
> That's a osm-carto problem, not a tagging problem.  Let's work out the
> tagging situation first, then we can worry about carto.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-ja] 半鐘について

[tomoya muramoto]

man_made=campanileという選択肢もありますが、
man_made=tower + tower:type=bell_towerでよいと思いますよ。
https://wiki.openstreetmap.org/wiki/JA:Tag:man_made%3Dcampanile

(機能を考えたらtower:type=sirenのほうが近いかもしれませんが、物理的にはtower:type=bell_towerですし)

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

Re: [Talk-us] Trunk

[Evin Fairchild]

I'm amazed that NE2's definition hasn't been removed after 7 years. It must
not have been that controversial or else someone would have removed it.
Seems like you just don't agree with his opinion and just really have some
personal problems with that guy. I know he engaged in some really dumb
stuff like unilaterally changing all the US highways to trunk and he
ultimately got banned for a turn restriction dispute with you over a parclo
interchange in Florida, but he's not the only one who believes that many US
highways are deserving of trunk status given the amount of traffic they
receive and their importance in a region's highway network.

On Sat, Oct 14, 2017 at 8:02 PM, Paul Johnson  wrote:

>
>
> On Sat, Oct 14, 2017 at 9:43 PM, Evin Fairchild 
> wrote:
>
>>
>>
>> On Oct 14, 2017 5:41 PM, "Paul Johnson"  wrote:
>>
>>
>>
>> On Sat, Oct 14, 2017 at 7:28 PM, Evin Fairchild 
>> wrote:
>>
>>>
>>>
>>> On Oct 14, 2017 4:25 PM, "Paul Johnson"  wrote:
>>>
>>>
>>>
>>> On Sat, Oct 14, 2017 at 6:08 PM, Evin Fairchild 
>>> wrote:
>>>
 On Oct 14, 2017 2:04 PM, "Wolfgang Zenker" 
 wrote:

 Hi,

 it looks to me that this discussion is going in circles, not forward
 at the moment. IMHO it does not make a lot of sense to argue what might
 be the true meaning of "trunk". Instead, we should concentrate on what
 it should mean, document this meaning if we can agree on one and don't
 worry to much about what other maps or different parts of the world
 think a "trunk" is.


 Yeah, the whole reason why this discussion hasn't resulted in a
 consensus for 7+ years is because people have dug in their heels so much
 and said "trunk roads can only be divided highways, no its, ands, or buts."
 I support what is written on the wiki that says that it is the second most
 important road after motorway. I haven't seen a single compelling reason to
 believe that trunk should only apply to divided highways. You can still
 tell whether a trunk is divided at low zooms based on how thick the line 
 is.

>>>
>>> I'm OK with single carriageway trunks, if they're controlled access,
>>> like, say, the Chickasaw Turnpike, and similarly constructed roads.  The
>>> single carriageway parts of US 395 or US 97 in eastern Oregon, US 400 in
>>> Kansas or US 75 in Oklahoma, though?  They're all solid primaries.
>>>
>>>
>>> You actually think that US 97, the main artery thru Central Oregon that
>>> passes thru the Bend area which has a 75K population and a metro population
>>> of 100K shouldn't be connected to the outside world with a trunk road?
>>>
>>
>> Yes.  Because for the majority of that length that isn't between US 20
>> and County Road 40 is, for all practical purposes, the same generic two
>> lane, shoulderless ribbon of pavement that pretty much any two lane Texas
>> FM or RM road, or pretty much any other similar road in the American west.
>> Primary is more than ample for such a road.
>>
>>
>> That's not accurate to compare a US highway to some podunk FM/RM road out
>> in the middle of nowhere in Texas. US 97 has way more traffic and very
>> deserving of its trunk road designation. Most US highways are, except in
>> places where they parallel an interstate or other freeway. BTW, this is
>> what is written on the wiki.
>>
>
>  Which was updated by NE2 to skew towards his view of the situation.  Any
> edits by him have negative value at this point.  Disconnect his reality
> from actual reality.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Paul Johnson]

On Sat, Oct 14, 2017 at 9:43 PM, Evin Fairchild  wrote:

>
>
> On Oct 14, 2017 5:41 PM, "Paul Johnson"  wrote:
>
> Or, map it cleanly to limited access expressways and super2s.  I really
> think people are trying to overthink this a bit; being a little less
> subjective isn't necessarily a bad thing.
>
>
> No, just no. I don't like looking at the US at a low zoom and seeing
> disjointed bits of trunk that aren't connected to anything. Makes the US
> map look bad.
>

That's a osm-carto problem, not a tagging problem.  Let's work out the
tagging situation first, then we can worry about carto.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Paul Johnson]

On Sat, Oct 14, 2017 at 9:43 PM, Evin Fairchild  wrote:

>
>
> On Oct 14, 2017 5:41 PM, "Paul Johnson"  wrote:
>
>
>
> On Sat, Oct 14, 2017 at 7:28 PM, Evin Fairchild 
> wrote:
>
>>
>>
>> On Oct 14, 2017 4:25 PM, "Paul Johnson"  wrote:
>>
>>
>>
>> On Sat, Oct 14, 2017 at 6:08 PM, Evin Fairchild 
>> wrote:
>>
>>> On Oct 14, 2017 2:04 PM, "Wolfgang Zenker" 
>>> wrote:
>>>
>>> Hi,
>>>
>>> it looks to me that this discussion is going in circles, not forward
>>> at the moment. IMHO it does not make a lot of sense to argue what might
>>> be the true meaning of "trunk". Instead, we should concentrate on what
>>> it should mean, document this meaning if we can agree on one and don't
>>> worry to much about what other maps or different parts of the world
>>> think a "trunk" is.
>>>
>>>
>>> Yeah, the whole reason why this discussion hasn't resulted in a
>>> consensus for 7+ years is because people have dug in their heels so much
>>> and said "trunk roads can only be divided highways, no its, ands, or buts."
>>> I support what is written on the wiki that says that it is the second most
>>> important road after motorway. I haven't seen a single compelling reason to
>>> believe that trunk should only apply to divided highways. You can still
>>> tell whether a trunk is divided at low zooms based on how thick the line is.
>>>
>>
>> I'm OK with single carriageway trunks, if they're controlled access,
>> like, say, the Chickasaw Turnpike, and similarly constructed roads.  The
>> single carriageway parts of US 395 or US 97 in eastern Oregon, US 400 in
>> Kansas or US 75 in Oklahoma, though?  They're all solid primaries.
>>
>>
>> You actually think that US 97, the main artery thru Central Oregon that
>> passes thru the Bend area which has a 75K population and a metro population
>> of 100K shouldn't be connected to the outside world with a trunk road?
>>
>
> Yes.  Because for the majority of that length that isn't between US 20 and
> County Road 40 is, for all practical purposes, the same generic two lane,
> shoulderless ribbon of pavement that pretty much any two lane Texas FM or
> RM road, or pretty much any other similar road in the American west.
> Primary is more than ample for such a road.
>
>
> That's not accurate to compare a US highway to some podunk FM/RM road out
> in the middle of nowhere in Texas. US 97 has way more traffic and very
> deserving of its trunk road designation. Most US highways are, except in
> places where they parallel an interstate or other freeway. BTW, this is
> what is written on the wiki.
>

 Which was updated by NE2 to skew towards his view of the situation.  Any
edits by him have negative value at this point.  Disconnect his reality
from actual reality.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Evin Fairchild]

On Oct 14, 2017 5:41 PM, "Paul Johnson"  wrote:



On Sat, Oct 14, 2017 at 7:28 PM, Evin Fairchild  wrote:

>
>
> On Oct 14, 2017 4:25 PM, "Paul Johnson"  wrote:
>
>
>
> On Sat, Oct 14, 2017 at 6:08 PM, Evin Fairchild 
> wrote:
>
>> On Oct 14, 2017 2:04 PM, "Wolfgang Zenker" 
>> wrote:
>>
>> Hi,
>>
>> it looks to me that this discussion is going in circles, not forward
>> at the moment. IMHO it does not make a lot of sense to argue what might
>> be the true meaning of "trunk". Instead, we should concentrate on what
>> it should mean, document this meaning if we can agree on one and don't
>> worry to much about what other maps or different parts of the world
>> think a "trunk" is.
>>
>>
>> Yeah, the whole reason why this discussion hasn't resulted in a consensus
>> for 7+ years is because people have dug in their heels so much and said
>> "trunk roads can only be divided highways, no its, ands, or buts." I
>> support what is written on the wiki that says that it is the second most
>> important road after motorway. I haven't seen a single compelling reason to
>> believe that trunk should only apply to divided highways. You can still
>> tell whether a trunk is divided at low zooms based on how thick the line is.
>>
>
> I'm OK with single carriageway trunks, if they're controlled access, like,
> say, the Chickasaw Turnpike, and similarly constructed roads.  The single
> carriageway parts of US 395 or US 97 in eastern Oregon, US 400 in Kansas or
> US 75 in Oklahoma, though?  They're all solid primaries.
>
>
> You actually think that US 97, the main artery thru Central Oregon that
> passes thru the Bend area which has a 75K population and a metro population
> of 100K shouldn't be connected to the outside world with a trunk road?
>

Yes.  Because for the majority of that length that isn't between US 20 and
County Road 40 is, for all practical purposes, the same generic two lane,
shoulderless ribbon of pavement that pretty much any two lane Texas FM or
RM road, or pretty much any other similar road in the American west.
Primary is more than ample for such a road.


That's not accurate to compare a US highway to some podunk FM/RM road out
in the middle of nowhere in Texas. US 97 has way more traffic and very
deserving of its trunk road designation. Most US highways are, except in
places where they parallel an interstate or other freeway. BTW, this is
what is written on the wiki.



>
>
>> The definition of "trunk" that I have used so far: A highway that is of
>> the same network importance as a primary, but specifically constructed
>> for fast traffic.
>>
>>
>> I like this definition. There are quite a few two lane roads that are
>> built for speed, but may still have some at grade intersections.
>>
>
> There's still a fundamental difference between a controlled or limited
> access route that isn't a freeway, and a two lane road without hard
> shoulders that has a 70 mph speed limit.
>
>
> Yeah, true. It's probably a more subjective definition. I think we ought
> to set a population of a city that should be connected to other places by
> trunk roads.
>

Or, map it cleanly to limited access expressways and super2s.  I really
think people are trying to overthink this a bit; being a little less
subjective isn't necessarily a bad thing.


No, just no. I don't like looking at the US at a low zoom and seeing
disjointed bits of trunk that aren't connected to anything. Makes the US
map look bad.

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

[Talk-it] Nomi di fiumi e torrenti, e (ab)uso di waterway=river

[Daniele]

Anche se è da poco che mappo io sarei dell'opinione che Fiume e Torrente 
dovrebbero fare parte del nome.
Ciò non tanto per il rendering quanto perché il nome di tutte le way è scritto 
con nome comune seguito dal nome proprio, cioè come una strada cittadina viene 
indicata Via, Corso, Viale ecc. troverei logico che anche le "vie d'acqua" 
fossero specificate nel nome se sono Fiume, Torrente, Rio, Canale ecc.
È certamente vero che colloquialmente si dice il Po, il Tevere, l'Adige ma solo 
perché la parola "fiume" viene sottintesa, mentre dicendo espressamente Fiume 
Po ecc. l'espressione risulterebbe più formale, ma anche più corretta.
Inoltre quelle (rare) volte che sul ponte che lo scavalca vi è la targa 
indicante il corso d'acqua superato mi sembra ci sia scritto solitamente,  ad 
esempio "Fiume Po" , e non semplicemente "Po"

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

Re: [Talk-us] Trunk

[Paul Johnson]

On Sat, Oct 14, 2017 at 7:28 PM, Evin Fairchild  wrote:

>
>
> On Oct 14, 2017 4:25 PM, "Paul Johnson"  wrote:
>
>
>
> On Sat, Oct 14, 2017 at 6:08 PM, Evin Fairchild 
> wrote:
>
>> On Oct 14, 2017 2:04 PM, "Wolfgang Zenker" 
>> wrote:
>>
>> Hi,
>>
>> it looks to me that this discussion is going in circles, not forward
>> at the moment. IMHO it does not make a lot of sense to argue what might
>> be the true meaning of "trunk". Instead, we should concentrate on what
>> it should mean, document this meaning if we can agree on one and don't
>> worry to much about what other maps or different parts of the world
>> think a "trunk" is.
>>
>>
>> Yeah, the whole reason why this discussion hasn't resulted in a consensus
>> for 7+ years is because people have dug in their heels so much and said
>> "trunk roads can only be divided highways, no its, ands, or buts." I
>> support what is written on the wiki that says that it is the second most
>> important road after motorway. I haven't seen a single compelling reason to
>> believe that trunk should only apply to divided highways. You can still
>> tell whether a trunk is divided at low zooms based on how thick the line is.
>>
>
> I'm OK with single carriageway trunks, if they're controlled access, like,
> say, the Chickasaw Turnpike, and similarly constructed roads.  The single
> carriageway parts of US 395 or US 97 in eastern Oregon, US 400 in Kansas or
> US 75 in Oklahoma, though?  They're all solid primaries.
>
>
> You actually think that US 97, the main artery thru Central Oregon that
> passes thru the Bend area which has a 75K population and a metro population
> of 100K shouldn't be connected to the outside world with a trunk road?
>

Yes.  Because for the majority of that length that isn't between US 20 and
County Road 40 is, for all practical purposes, the same generic two lane,
shoulderless ribbon of pavement that pretty much any two lane Texas FM or
RM road, or pretty much any other similar road in the American west.
Primary is more than ample for such a road.


>
>
>> The definition of "trunk" that I have used so far: A highway that is of
>> the same network importance as a primary, but specifically constructed
>> for fast traffic.
>>
>>
>> I like this definition. There are quite a few two lane roads that are
>> built for speed, but may still have some at grade intersections.
>>
>
> There's still a fundamental difference between a controlled or limited
> access route that isn't a freeway, and a two lane road without hard
> shoulders that has a 70 mph speed limit.
>
>
> Yeah, true. It's probably a more subjective definition. I think we ought
> to set a population of a city that should be connected to other places by
> trunk roads.
>

Or, map it cleanly to limited access expressways and super2s.  I really
think people are trying to overthink this a bit; being a little less
subjective isn't necessarily a bad thing.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Evin Fairchild]

On Oct 14, 2017 4:25 PM, "Paul Johnson"  wrote:



On Sat, Oct 14, 2017 at 6:08 PM, Evin Fairchild  wrote:

> On Oct 14, 2017 2:04 PM, "Wolfgang Zenker" 
> wrote:
>
> Hi,
>
> it looks to me that this discussion is going in circles, not forward
> at the moment. IMHO it does not make a lot of sense to argue what might
> be the true meaning of "trunk". Instead, we should concentrate on what
> it should mean, document this meaning if we can agree on one and don't
> worry to much about what other maps or different parts of the world
> think a "trunk" is.
>
>
> Yeah, the whole reason why this discussion hasn't resulted in a consensus
> for 7+ years is because people have dug in their heels so much and said
> "trunk roads can only be divided highways, no its, ands, or buts." I
> support what is written on the wiki that says that it is the second most
> important road after motorway. I haven't seen a single compelling reason to
> believe that trunk should only apply to divided highways. You can still
> tell whether a trunk is divided at low zooms based on how thick the line is.
>

I'm OK with single carriageway trunks, if they're controlled access, like,
say, the Chickasaw Turnpike, and similarly constructed roads.  The single
carriageway parts of US 395 or US 97 in eastern Oregon, US 400 in Kansas or
US 75 in Oklahoma, though?  They're all solid primaries.


You actually think that US 97, the main artery thru Central Oregon that
passes thru the Bend area which has a 75K population and a metro population
of 100K shouldn't be connected to the outside world with a trunk road?



> The definition of "trunk" that I have used so far: A highway that is of
> the same network importance as a primary, but specifically constructed
> for fast traffic.
>
>
> I like this definition. There are quite a few two lane roads that are
> built for speed, but may still have some at grade intersections.
>

There's still a fundamental difference between a controlled or limited
access route that isn't a freeway, and a two lane road without hard
shoulders that has a 70 mph speed limit.


Yeah, true. It's probably a more subjective definition. I think we ought to
set a population of a city that should be connected to other places by
trunk roads.

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

Re: [Talk-us] Trunk

[Paul Johnson]

On Sat, Oct 14, 2017 at 6:25 PM, Paul Johnson  wrote:
>
> There's still a fundamental difference between a controlled or limited
> access route that isn't a freeway, and a two lane road without hard
> shoulders that has a 70 mph speed limit.
>


To expand on this, it's pretty safe to say there's a big difference between
the 55 mph OR 22 between OR 223 Spur and OR 99E Business, and the 70 mph
Texas Farm-to-Market 2161 between I 40 and US 60.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Paul Johnson]

On Sat, Oct 14, 2017 at 6:08 PM, Evin Fairchild  wrote:

> On Oct 14, 2017 2:04 PM, "Wolfgang Zenker" 
> wrote:
>
> Hi,
>
> it looks to me that this discussion is going in circles, not forward
> at the moment. IMHO it does not make a lot of sense to argue what might
> be the true meaning of "trunk". Instead, we should concentrate on what
> it should mean, document this meaning if we can agree on one and don't
> worry to much about what other maps or different parts of the world
> think a "trunk" is.
>
>
> Yeah, the whole reason why this discussion hasn't resulted in a consensus
> for 7+ years is because people have dug in their heels so much and said
> "trunk roads can only be divided highways, no its, ands, or buts." I
> support what is written on the wiki that says that it is the second most
> important road after motorway. I haven't seen a single compelling reason to
> believe that trunk should only apply to divided highways. You can still
> tell whether a trunk is divided at low zooms based on how thick the line is.
>

I'm OK with single carriageway trunks, if they're controlled access, like,
say, the Chickasaw Turnpike, and similarly constructed roads.  The single
carriageway parts of US 395 or US 97 in eastern Oregon, US 400 in Kansas or
US 75 in Oklahoma, though?  They're all solid primaries.


> The definition of "trunk" that I have used so far: A highway that is of
> the same network importance as a primary, but specifically constructed
> for fast traffic.
>
>
> I like this definition. There are quite a few two lane roads that are
> built for speed, but may still have some at grade intersections.
>

There's still a fundamental difference between a controlled or limited
access route that isn't a freeway, and a two lane road without hard
shoulders that has a 70 mph speed limit.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Evin Fairchild]

On Oct 14, 2017 2:04 PM, "Wolfgang Zenker" 
wrote:

Hi,

it looks to me that this discussion is going in circles, not forward
at the moment. IMHO it does not make a lot of sense to argue what might
be the true meaning of "trunk". Instead, we should concentrate on what
it should mean, document this meaning if we can agree on one and don't
worry to much about what other maps or different parts of the world
think a "trunk" is.


Yeah, the whole reason why this discussion hasn't resulted in a consensus
for 7+ years is because people have dug in their heels so much and said
"trunk roads can only be divided highways, no its, ands, or buts." I
support what is written on the wiki that says that it is the second most
important road after motorway. I haven't seen a single compelling reason to
believe that trunk should only apply to divided highways. You can still
tell whether a trunk is divided at low zooms based on how thick the line is.


The definition of "trunk" that I have used so far: A highway that is of
the same network importance as a primary, but specifically constructed
for fast traffic.

Wolfgang

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


I like this definition. There are quite a few two lane roads that are built
for speed, but may still have some at grade intersections.

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

Re: [Talk-it] Ultimo tratto relazione Alpinistica

[Alfredo Gattai]

In effetti nella proposta relativa al cai_scale e nella wiki abbiamo
scritto che il cai_scale e' per la relazione. Non e' che abbiamo "proibito"
di metterlo sulla way ma non avrebbe molto senso farlo. il sac_scale gia'
universalmente adottato assolve a questo compito di distinguere le singole
way, il cai_scale per il suolo italiano mette a disposizione di tutti la
valutazione del CAI sull'interezza del percorso.

Il caso in questione e' particolarmente interessante perche' affronta un
problema non molto dibattuto fino ad ora.
Che cosa si intente per tratto alpinistico? La sac_scale prevede tratti di
"path-sentiero" con difficolta' alpinistiche e questo di per se puo' essere
fuorviante perche' comunemente chi fa alpinismo nonostante le chiami "vie"
ha ben chiara la differenza fra una via alpinistica ed un sentiero.

Dal mio punto di vista forse highway=path nonostante sia corredato di un
sac_scale=difficult_alpine_hiking non rappresenta adeguatamente quei tratti
che una persona esperta affronterebbe solo corredato di imbraco, corda e
materiale per proteggersi (chiodi, nut, friends)

Dato che sembra ormai aver preso piede highway=via_ferrata per tutti quei
tratti attrezzati con cavi, pioli, etc forse bisognerebbe ipotizzare una
highway=climb o qualcosa del genere.

Esiste gia' una proposta per climbing route ma che e' specifica e vere e
proprie vie di arrampicata infatti spesso possono essere rappresentate solo
con un nodo o al massimo due molto vicini.

Non conosco la via in questione quindi dare un giudizio e' difficile ma
direi che la proposta di Volker e' un'idea se il percorso nella sua
interezza non eccede la cai_scale=EEA ma se e' piu' difficile forse
conviene fare la relazione solo per il tratto non alpinistico e lasciare
per il tratto alpinistico solo la way con un sac_scale adeguato.

Se hai un esempio fotografico o se hai informazioni sulla via in questione
da consultare potremmo usarla come caso di studio.

Ciao
Alfredo





2017-10-14 22:56 GMT+02:00 Ivo Reano :

> Interessante questa distinzione tra il sac_scale sulla way, accettata in
> modo universale e il cai_scale sulla relazione.
>
> Mi piacerebbe sentire cosa dice Alfredo e il sosec
> Però devo aggiungere che da neofito per i sentieri a catasto regionale di
> cui sto creando le relazioni, effettivamente ho già fatto cosi:
> il sac_scale lo lascio cosi com'è se presente e sul percorso metto quello
> deciso dal rilevatore che corrisponde al valore più impegnativo dell'intero
> percorso.
> Non è detto che sia la parte finale, a volte, raro certamente, è un tratto
> intermedio che presenta difficoltà superiori al resto.
> In effetti convincere i nuovi rilevatori che la scala del percorso è la
> massima e non la media è difficile. Però questa è una regola!
>
> Il giorno 14 ottobre 2017 11:44, Volker Schmidt  ha
> scritto:
>
>> Il sac_scale  va messo
>> sul way individuale e può variare da pezzo a pezzo del sentiero.
>> Il tag cai_scale
>>  (ancora
>> in fase di proposta) si applica al sentiero nella sua totalità (e solo in
>> Italia). Quindi andrebbe sulla relazione e non sui ways individuali che
>> compongono il sentiero.
>> Nel tuo caso, dove c'è una parte del sentiero che è più facile ed una,
>> successiva, più impegnativa, si potrebbe pensare a due relazioni raccolti
>> in una super-relazione, mettendo valori di cai_scale diversi sulle due
>> relazioni.
>> Il tag ref contiene sempre il numero del sentiero, cioè il sentiero
>> SATxyz o CAIxyz o AVSxyz il valore numerico "xyz". In casi dove non c'è
>> numero, ma una lettera o una combinazione di lettera e numero riporti
>> questi.
>>
>>
>>
>> 2017-10-14 10:28 GMT+02:00 Cascafico Giovanni :
>>
>>> Direi di no: la difficoltà per chi intraprende il percorso della
>>> relazione  é sempre quella del tratto peggiore è il viaggiatore é meglio lo
>>> sappia.
>>>
>>> Se hai info dettagliate, assegna i relativi tag alle way, spezzandole
>>> all'occorrenza.
>>>
>>> Il 14/ott/2017 08:57, "angelo mornata"  ha
>>> scritto:
>>>
 In una Relazione, quando l'ultimo tratto è alpinistico va Divisa, e
 fatta una relazione a parte per il suddetto tratto?

 Esempio: Partenza, arrivo al bivacco una relazione, bivacco cima
 un'altra relazione?


 Che Ref va messo su una via Alpinistica?


 Grazie e scusate l'ignoranza


 Angelo

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


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

Re: [Talk-it] Falegnameria / Segheria

[Martin Koppenhoefer]

sent from a phone

> On 14. Oct 2017, at 10:37, demon.box  wrote:
> 
> che va sicuramente bene per la falegnameria ma invece un segheria non è
> esattamente la stessa cosa...
> 
> che dite?


craft=sawmill è usato 2500 volte. Io avrei più cercato in man_made=sawmill 
oppure man_made=works e qualcosa come works=sawmill, ma forse è una questione 
di scala (craft=piccolo, works = scala industriale), le “segherie” come le ho 
viste io, erano sempre su aree relativamente “grandi”, e in scala industriale.
Ciao, Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] Trunk

[Wolfgang Zenker]

Hi,

it looks to me that this discussion is going in circles, not forward
at the moment. IMHO it does not make a lot of sense to argue what might
be the true meaning of "trunk". Instead, we should concentrate on what
it should mean, document this meaning if we can agree on one and don't
worry to much about what other maps or different parts of the world
think a "trunk" is.

The definition of "trunk" that I have used so far: A highway that is of
the same network importance as a primary, but specifically constructed
for fast traffic.

Wolfgang

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

Re: [Talk-it] Ultimo tratto relazione Alpinistica

[Ivo Reano]

Interessante questa distinzione tra il sac_scale sulla way, accettata in
modo universale e il cai_scale sulla relazione.

Mi piacerebbe sentire cosa dice Alfredo e il sosec
Però devo aggiungere che da neofito per i sentieri a catasto regionale di
cui sto creando le relazioni, effettivamente ho già fatto cosi:
il sac_scale lo lascio cosi com'è se presente e sul percorso metto quello
deciso dal rilevatore che corrisponde al valore più impegnativo dell'intero
percorso.
Non è detto che sia la parte finale, a volte, raro certamente, è un tratto
intermedio che presenta difficoltà superiori al resto.
In effetti convincere i nuovi rilevatori che la scala del percorso è la
massima e non la media è difficile. Però questa è una regola!

Il giorno 14 ottobre 2017 11:44, Volker Schmidt  ha
scritto:

> Il sac_scale  va messo
> sul way individuale e può variare da pezzo a pezzo del sentiero.
> Il tag cai_scale
>  (ancora
> in fase di proposta) si applica al sentiero nella sua totalità (e solo in
> Italia). Quindi andrebbe sulla relazione e non sui ways individuali che
> compongono il sentiero.
> Nel tuo caso, dove c'è una parte del sentiero che è più facile ed una,
> successiva, più impegnativa, si potrebbe pensare a due relazioni raccolti
> in una super-relazione, mettendo valori di cai_scale diversi sulle due
> relazioni.
> Il tag ref contiene sempre il numero del sentiero, cioè il sentiero SATxyz
> o CAIxyz o AVSxyz il valore numerico "xyz". In casi dove non c'è numero, ma
> una lettera o una combinazione di lettera e numero riporti questi.
>
>
>
> 2017-10-14 10:28 GMT+02:00 Cascafico Giovanni :
>
>> Direi di no: la difficoltà per chi intraprende il percorso della
>> relazione  é sempre quella del tratto peggiore è il viaggiatore é meglio lo
>> sappia.
>>
>> Se hai info dettagliate, assegna i relativi tag alle way, spezzandole
>> all'occorrenza.
>>
>> Il 14/ott/2017 08:57, "angelo mornata"  ha
>> scritto:
>>
>>> In una Relazione, quando l'ultimo tratto è alpinistico va Divisa, e
>>> fatta una relazione a parte per il suddetto tratto?
>>>
>>> Esempio: Partenza, arrivo al bivacco una relazione, bivacco cima
>>> un'altra relazione?
>>>
>>>
>>> Che Ref va messo su una via Alpinistica?
>>>
>>>
>>> Grazie e scusate l'ignoranza
>>>
>>>
>>> Angelo
>>>
>>> ___
>>> Talk-it mailing list
>>> Talk-it@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-it
>>>
>>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] Trunk

[Bradley White]

The linked example is an OSM screenshot? So yes, especially if it is
strictly adhering to trunk==expressway, then they will be explicitly
marked. This is circular. USGS maps emphasize roads when they are
multi-lane highways that aren't freeways, not when they are
expressways. Not every multi-lane highway is an expressway, and not
every multi-lane highway is a trunk road.

On Sat, Oct 14, 2017 at 1:37 PM, Paul Johnson  wrote:
>
>
> On Sat, Oct 14, 2017 at 3:19 PM, Bradley White 
> wrote:
>>
>> On Sat, Oct 14, 2017 at 12:53 PM, Nathan Mills  wrote:
>> > Road maps in the US have long differentiated between freeway/expressway
>> > and
>> > has had both of those clearly different than US and state highways we'd
>> > be
>> > tagging as primary. Map users expect to see expressways shown
>> > differently.
>>
>> Could you show me an example of a US road atlas that explicitly
>> demarcates expressways? I have legitimately tried to find one but have
>> not been able to. Most US maps I've seen show freeways & toll roads
>> explicitly, but not expressways. Some maps might use a different
>> casing style to denote a divided highway, but the underlying color of
>> the line still represents the importance of the road. Which is the
>> point I'm trying to get at, that a highway being divided or not is
>> orthogonal to its importance.
>
>
> Just googling for it, I do find
> https://upload.wikimedia.org/wikipedia/commons/b/b3/Portland_map.png which
> has 99E where McLoughlin Boulevard is an expressway, and the Milwaukie
> Expressway, in green.  USGS's topo maps of Portland also show the Milwaukie
> Expressway as an expressway, though also shows Interstate 205 as an
> expressway instead of a freeway (which I think we'd all agree would be
> incorrect).  USGS also shows (albeit very outdated at this point) US 412 as
> being an expressway, different from a freeway, east of where the (then still
> unbuilt) Creek Turnpike now joins the Rogers Turnpike.

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

Re: [Talk-us] Trunk

[Paul Johnson]

On Sat, Oct 14, 2017 at 3:19 PM, Bradley White 
wrote:

> On Sat, Oct 14, 2017 at 12:53 PM, Nathan Mills  wrote:
> > Road maps in the US have long differentiated between freeway/expressway
> and
> > has had both of those clearly different than US and state highways we'd
> be
> > tagging as primary. Map users expect to see expressways shown
> differently.
>
> Could you show me an example of a US road atlas that explicitly
> demarcates expressways? I have legitimately tried to find one but have
> not been able to. Most US maps I've seen show freeways & toll roads
> explicitly, but not expressways. Some maps might use a different
> casing style to denote a divided highway, but the underlying color of
> the line still represents the importance of the road. Which is the
> point I'm trying to get at, that a highway being divided or not is
> orthogonal to its importance.
>

Just googling for it, I do find
https://upload.wikimedia.org/wikipedia/commons/b/b3/Portland_map.png which
has 99E where McLoughlin Boulevard is an expressway, and the Milwaukie
Expressway, in green.  USGS's topo maps of Portland also show the Milwaukie
Expressway as an expressway, though also shows Interstate 205 as an
expressway instead of a freeway (which I think we'd all agree would be
incorrect).  USGS also shows (albeit very outdated at this point) US 412 as
being an expressway, different from a freeway, east of where the (then
still unbuilt) Creek Turnpike now joins the Rogers Turnpike.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Evin Fairchild]

As I said previously, and I think it bears repeating, it's very easy to
tell if a trunk is divided or undivided when you look at US or Canada at
zoom 5 on the standard layer. Divided trunks show up as a thicker line than
undivided trunks.

Also worth noting that Google maps doesn't display divided highways any
different than undivided highways. They all are colored yellow.

-Evin (compdude)

On Oct 14, 2017 1:20 PM, "Bradley White"  wrote:

> On Sat, Oct 14, 2017 at 12:53 PM, Nathan Mills  wrote:
> > Road maps in the US have long differentiated between freeway/expressway
> and
> > has had both of those clearly different than US and state highways we'd
> be
> > tagging as primary. Map users expect to see expressways shown
> differently.
>
> Could you show me an example of a US road atlas that explicitly
> demarcates expressways? I have legitimately tried to find one but have
> not been able to. Most US maps I've seen show freeways & toll roads
> explicitly, but not expressways. Some maps might use a different
> casing style to denote a divided highway, but the underlying color of
> the line still represents the importance of the road. Which is the
> point I'm trying to get at, that a highway being divided or not is
> orthogonal to its importance.
>
> > It's less work on so many levels also. Creating a new tag requires
> > significant work on the render side, but doesn't really gain us much over
> > just using primary for roads that some think are important enough to be a
> > trunk but are undivided. The wiki definition for primary is already "the
> > most important non-motorway route between two cities" (essentially, and
> > ignoring the variation in use between rural and urban areas)
>
> This is incorrect. 'Tag:highway=primary' gives "A highway linking
> large towns". 'Tag:highway=trunk' gives "Important roads that are not
> motorways", and explicitly lists in the US tagging application that "a
> major intercity highway" is a correct use of the trunk tag in the US.
> 'Highway:international_equivalence' as well as 'Key:highway' give the
> same set of definitions. Where are you seeing that primary is "the
> most important non-motorway route between two cities"?
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] New OSM Quick-Fix service

[Tomas Straupis]

2017-10-14 15:57 GMT+03:00 Jochen Topf wrote:
> Do I understand this correctly? You are creating tags in the OSM
> database for your private tool? I hope there is some misunderstanding
> here, because that isn't acceptable behaviour.

  The problem is much much larger.

  This whole wikidata unfortunate story has been going on for two years now.

  During that time Yuri was asked by members of different communities
to stop. He was asked once, twice, three times and sometimes even
more. All of that was ignored.
  He was asked to contact local communities and he did not.
  He was bulldozing his "wikidata will save the world" idea and was
given examples that he is wrong (same thing can be achieved without
adding new tags/data to OSM).
  He was asked to stop at least until this is sorted out. Once again
he ignored the community and not only keeps doing his stuff, but is
increasing in speed and involving other people to accumulate the
damage.

  Now I have already reverted a number of edits by people, who were
fooled by Yuri's tool that automatically adding tag B according to tag
A can help to automatically fix tag A, according to this derived tag B
(logical nonsense). I reverted edits where not wikidata, but WIKIPEDIA
tag was changed to incorrect one using Yuri's "QA" tool. Something
which Yuri was claiming should never happen - he said he is "only
after wikidata tags".

  The only good thing is that we now know changeset pattern. So this
could be added to the list alongside maps.kgb.me and reverted
"semiautomatically". While this does not seem totally right, I do not
see any other solution to this. Unfortunately.

-- 
Tomas

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

Re: [Talk-us] Trunk

[Bradley White]

On Sat, Oct 14, 2017 at 12:53 PM, Nathan Mills  wrote:
> Road maps in the US have long differentiated between freeway/expressway and
> has had both of those clearly different than US and state highways we'd be
> tagging as primary. Map users expect to see expressways shown differently.

Could you show me an example of a US road atlas that explicitly
demarcates expressways? I have legitimately tried to find one but have
not been able to. Most US maps I've seen show freeways & toll roads
explicitly, but not expressways. Some maps might use a different
casing style to denote a divided highway, but the underlying color of
the line still represents the importance of the road. Which is the
point I'm trying to get at, that a highway being divided or not is
orthogonal to its importance.

> It's less work on so many levels also. Creating a new tag requires
> significant work on the render side, but doesn't really gain us much over
> just using primary for roads that some think are important enough to be a
> trunk but are undivided. The wiki definition for primary is already "the
> most important non-motorway route between two cities" (essentially, and
> ignoring the variation in use between rural and urban areas)

This is incorrect. 'Tag:highway=primary' gives "A highway linking
large towns". 'Tag:highway=trunk' gives "Important roads that are not
motorways", and explicitly lists in the US tagging application that "a
major intercity highway" is a correct use of the trunk tag in the US.
'Highway:international_equivalence' as well as 'Key:highway' give the
same set of definitions. Where are you seeing that primary is "the
most important non-motorway route between two cities"?

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

Re: [OSM-talk-fr] Certificat Osmose expiré

[Jocelyn Jaubert]

Bonjour,

Le 14/10/2017 à 10:40, Francois Gouget a écrit :
> 
> Le certificat de https://osmose.openstreetmap.fr/ a expiré aujourd'hui 
> à 00:15 :
> 
> osmose.openstreetmap.fr uses an invalid security certificate.

C'est corrigé, merci d'avoir prévenu.

-- 
Jocelyn

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

Re: [Talk-us] Trunk

[Nathan Mills]

I think I've said this before, but I'm mostly in agreement with Paul's 
position. Trunk should apply to divided, limited but not controlled access 
highways. Other uses should be exceptions in the same vein as rural interstates 
with a few at-grade intersections keeping their motorway status.

Expressways may often not be of more than local importance, though they often 
are. US 412 in Arkansas is an example which should be part trunk part primary, 
IMO. Even when they are of only local importance, they should still get the 
trunk tag, same as a short motorway still being a motorway despite being 
completely irrelevant to the overall national road network.

Road maps in the US have long differentiated between freeway/expressway and has 
had both of those clearly different than US and state highways we'd be tagging 
as primary. Map users expect to see expressways shown differently. We have the 
tag, it already renders more like motorway in a similar style to other maps, so 
it makes sense to me to work like other maps since it's what end users expect. 
Given that the tag is already there and is fit for purpose. Unless someone can 
show me a situation in which critical information can't be conveyed if an 
important, but undivided, road is tagged primary rather than trunk (Assuming 
the undivided section is not a short interruption in an otherwise continuous 
expressway) I just don't see the benefit of using it to mean "more important 
than primary" rather than "divided but not fully access controlled"

In short, both maps and common use in the US have historically had three main 
classes of paved road. Freeways/motorways, expressways/trunks, and everything 
else. The visual difference between the lower class roads was either based on 
network importance or whether it is a US or state highway, but the higher class 
(faster) roads have long been classified apart from everything else in a way 
that maps very well to motorway/trunk as it has generally used by most US 
mappers aside from NE2 thus far.

It's less work on so many levels also. Creating a new tag requires significant 
work on the render side, but doesn't really gain us much over just using 
primary for roads that some think are important enough to be a trunk but are 
undivided. The wiki definition for primary is already "the most important 
non-motorway route between two cities" (essentially, and ignoring the variation 
in use between rural and urban areas) I don't think any backend work is worth 
the insignificant increase in expressiveness of the map we'd get from using 
trunk as a better primary and introducing a separate tag to denote an 
expressway.

As far as Alaska goes, it's different enough I don't think it's at all 
unreasonable to adjust the rules a bit there, just like there is already some 
variation between states and countries on how to differentiate between 
primary/secondary/etc.

If the issue is the low zoom rendering of short trunk and motorway segments, 
that's a misfeature in carto, not a tagging issue. And not even so hard to fix 
now that route relations are so prevalent.

-Nathan


On October 14, 2017 1:23:39 PM EDT, Bradley White  
wrote:
>> The concept of expressway and freeway are reasonably well known
>concepts;
>> it makes a lot of sense to map trunk and motorway to those concepts.
>
>I agree with freeways but not with expressways. I have no data to back
>this claim up, but I'm fairly convinced that, while the average
>citizen could easily differentiate between "freeway" and "not
>freeway", they would be hard pressed to do the same with an
>expressway. Anecdotal, but even when I spent time in the Santa Clara
>area which has a robust expressway system, I never heard a single
>person say "and then get on the expressway...", or even the word
>'expressway' mentioned outside of it being the suffix of a road name.
>You're right that it's not a terribly difficult concept to understand
>and thus map, but I disagree that it's an important concept in
>explaining the road hierarchy in the US, so much so that we can equate
>an entire class of importance with them. We have a robust, clearly
>signposted freeway network in the US. We do not have the same with
>expressways. Roads tend to go in and out of "expressway" qualification
>depending on context, traffic levels of connecting roads, and highway
>budget & design policy. A road being built as an expressway is
>suggestive of its importance at best, and certainly not indicative.
>
>Edmonton has many roads around the east and west of the downtown area
>that are clearly built as expressways. However, they are only tagged
>secondary because, fundamentally, you only really need to use them to
>get around the immediate vicinity. Despite being very high quality
>roads, they aren't all that important in the grand scheme. I can point
>to many examples of urban roads that likely meet an expressway
>definition in my current home city of Reno, including one under

Re: [Talk-se] Ändringsset: 52111741

[Essin]

Nu fixat, det gick lätt med
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Reverter

/Essin

Den 11 oktober 2017 13:38 skrev Essin :

> Hej!
>
> Har detta åtgärdats än? Annars kan jag göra ett försök. JOSM-validatorn
> (över)reagerar ofta på byggnader som verkar vara korrekt taggade enligt
> Simple 3D buildings-systemet, så det är antagligen där problemet ligger.
>
> OSM-hälsningar,
> Essin
>
> Den 19 september 2017 18:55 skrev Tobias Johansson :
>
>> Hej
>>
>> Såg att en byggnad i Göteborg har oturligt ändrats (enligt mig fel). Jag
>> tror inte det är pga av någon elak anledning utan bara pga inte kännedom om
>> hur buildings 3d funkar.
>>
>> https://www.openstreetmap.org/changeset/52111741#map=19/57.70132/11.91397
>>
>> Jag vet inte riktigt hur man kan gå till väga för att reverta ändringen
>> men någon annan kanske har koll. Jag har lagt till en kommentar på
>> ändringssettet i fråga.
>>
>> --
>> MvH Tobias Johansson
>> E-Post: tj7712...@gmail.com
>>
>> ___
>> Talk-se mailing list
>> Talk-se@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-se
>>
>>
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-us] Trunk

[Evin Fairchild]

Still don't agree about osmand making trunks look like a divided highway/
expressway but whatever. Either way, if we tag only divided highways as
trunk just because a certain renderer makes trunk roads look like divided
highways (BTW, this is a better term to use here than expressway because it
causes less confusion), that actually is a textbook example of tagging for
the renderer.

-Evin (compdude)

On Oct 14, 2017 10:57 AM, "Bradley White"  wrote:

> I use Osmand frequently; the point of the cased-line style of the
> trunk & motorway tags is, agreeing with Paul here, to show some degree
> of access control. This is in-line with many paper road atlases,
> especially older ones. My point was that third-party applications
> choosing to use this style is their own pejorative, and we should not
> be basing tagging definitions on how third-party apps use the data. In
> regard to the trunk debate, I understand and fully respect Paul's
> position, but I personally disagree. I'm hoping the debate here will
> encourage the US OSM community in getting closer to an agreeable
> definition for trunk.
>
> On Sat, Oct 14, 2017 at 10:49 AM, Evin Fairchild 
> wrote:
> > To add onto what Bradley was saying about third-party applications, I
> just
> > want to add that I've done some fact-checking about a claim that Paul
> made
> > in a previous email about how Osmand renders trunks under the assumption
> > that they are expressways (to be clear, by this I mean divided highways
> w/
> > at-grade intersections). After some fact-checking, this claim receives a
> > truth rating of completely FALSE.
> >
> > Anyway, I looked at how Osmand renders motorways versus trunk and I don't
> > know how it is that you, Paul, can say that trunk is assumed to be like
> an
> > expressway  in Osmand's render. That is simply not true. The motorway in
> > Osmand, for those who are unfamiliar, is red with a thin blue outline
> around
> > it, whereas trunk is just an orange-red line without any other color
> > outlining it. This makes it look more like a single-carriageway road and
> > less like an expressway like Paul falsely claims. All it looks like is a
> > road that is of higher-importance than primary, and does NOT at all look
> > like it could be an expressway. Usually, when maps show a divided
> highway w/
> > at-grade intersections, it looks similar to a freeway, but a different
> > color, whereas an undivided two-lane road typically looks nothing like an
> > expressway or freeway. Thus, it is complete and utter lie to say that
> Osmand
> > makes the assumption that trunk roads are expressways. I don't know how
> > mkgmap shows trunk vs. motorway since I don't have a Garmin and thus
> cannot
> > test it out, but I don't trust that Paul is telling the truth here
> either.
> >
> > It's important to make truthful claims here, Paul; from now on, I will
> have
> > a VERY difficult time trusting anything you say. I know what I brought up
> > was kind of a side point, but I think it's important to call out BS when
> I
> > see it.
> >
> > -Evin (compdude)
> >
> >
> > On Sat, Oct 14, 2017 at 10:23 AM, Bradley White <
> theangrytom...@gmail.com>
> > wrote:
> >>
> >> > The concept of expressway and freeway are reasonably well known
> >> > concepts;
> >> > it makes a lot of sense to map trunk and motorway to those concepts.
> >>
> >> I agree with freeways but not with expressways. I have no data to back
> >> this claim up, but I'm fairly convinced that, while the average
> >> citizen could easily differentiate between "freeway" and "not
> >> freeway", they would be hard pressed to do the same with an
> >> expressway. Anecdotal, but even when I spent time in the Santa Clara
> >> area which has a robust expressway system, I never heard a single
> >> person say "and then get on the expressway...", or even the word
> >> 'expressway' mentioned outside of it being the suffix of a road name.
> >> You're right that it's not a terribly difficult concept to understand
> >> and thus map, but I disagree that it's an important concept in
> >> explaining the road hierarchy in the US, so much so that we can equate
> >> an entire class of importance with them. We have a robust, clearly
> >> signposted freeway network in the US. We do not have the same with
> >> expressways. Roads tend to go in and out of "expressway" qualification
> >> depending on context, traffic levels of connecting roads, and highway
> >> budget & design policy. A road being built as an expressway is
> >> suggestive of its importance at best, and certainly not indicative.
> >>
> >> Edmonton has many roads around the east and west of the downtown area
> >> that are clearly built as expressways. However, they are only tagged
> >> secondary because, fundamentally, you only really need to use them to
> >> get around the immediate vicinity. Despite being very high quality
> >> roads, they aren't all that important in the grand scheme. I can point
> >> 

Re: [Talk-us] Trunk

[Bradley White]

I use Osmand frequently; the point of the cased-line style of the
trunk & motorway tags is, agreeing with Paul here, to show some degree
of access control. This is in-line with many paper road atlases,
especially older ones. My point was that third-party applications
choosing to use this style is their own pejorative, and we should not
be basing tagging definitions on how third-party apps use the data. In
regard to the trunk debate, I understand and fully respect Paul's
position, but I personally disagree. I'm hoping the debate here will
encourage the US OSM community in getting closer to an agreeable
definition for trunk.

On Sat, Oct 14, 2017 at 10:49 AM, Evin Fairchild  wrote:
> To add onto what Bradley was saying about third-party applications, I just
> want to add that I've done some fact-checking about a claim that Paul made
> in a previous email about how Osmand renders trunks under the assumption
> that they are expressways (to be clear, by this I mean divided highways w/
> at-grade intersections). After some fact-checking, this claim receives a
> truth rating of completely FALSE.
>
> Anyway, I looked at how Osmand renders motorways versus trunk and I don't
> know how it is that you, Paul, can say that trunk is assumed to be like an
> expressway  in Osmand's render. That is simply not true. The motorway in
> Osmand, for those who are unfamiliar, is red with a thin blue outline around
> it, whereas trunk is just an orange-red line without any other color
> outlining it. This makes it look more like a single-carriageway road and
> less like an expressway like Paul falsely claims. All it looks like is a
> road that is of higher-importance than primary, and does NOT at all look
> like it could be an expressway. Usually, when maps show a divided highway w/
> at-grade intersections, it looks similar to a freeway, but a different
> color, whereas an undivided two-lane road typically looks nothing like an
> expressway or freeway. Thus, it is complete and utter lie to say that Osmand
> makes the assumption that trunk roads are expressways. I don't know how
> mkgmap shows trunk vs. motorway since I don't have a Garmin and thus cannot
> test it out, but I don't trust that Paul is telling the truth here either.
>
> It's important to make truthful claims here, Paul; from now on, I will have
> a VERY difficult time trusting anything you say. I know what I brought up
> was kind of a side point, but I think it's important to call out BS when I
> see it.
>
> -Evin (compdude)
>
>
> On Sat, Oct 14, 2017 at 10:23 AM, Bradley White 
> wrote:
>>
>> > The concept of expressway and freeway are reasonably well known
>> > concepts;
>> > it makes a lot of sense to map trunk and motorway to those concepts.
>>
>> I agree with freeways but not with expressways. I have no data to back
>> this claim up, but I'm fairly convinced that, while the average
>> citizen could easily differentiate between "freeway" and "not
>> freeway", they would be hard pressed to do the same with an
>> expressway. Anecdotal, but even when I spent time in the Santa Clara
>> area which has a robust expressway system, I never heard a single
>> person say "and then get on the expressway...", or even the word
>> 'expressway' mentioned outside of it being the suffix of a road name.
>> You're right that it's not a terribly difficult concept to understand
>> and thus map, but I disagree that it's an important concept in
>> explaining the road hierarchy in the US, so much so that we can equate
>> an entire class of importance with them. We have a robust, clearly
>> signposted freeway network in the US. We do not have the same with
>> expressways. Roads tend to go in and out of "expressway" qualification
>> depending on context, traffic levels of connecting roads, and highway
>> budget & design policy. A road being built as an expressway is
>> suggestive of its importance at best, and certainly not indicative.
>>
>> Edmonton has many roads around the east and west of the downtown area
>> that are clearly built as expressways. However, they are only tagged
>> secondary because, fundamentally, you only really need to use them to
>> get around the immediate vicinity. Despite being very high quality
>> roads, they aren't all that important in the grand scheme. I can point
>> to many examples of urban roads that likely meet an expressway
>> definition in my current home city of Reno, including one under
>> construction. It would be absurd to me to tag them as being second in
>> importance only to motorways just because they are well-built roads,
>> because they're unimportant outside of getting around the relatively
>> small Reno-Sparks metropolitan area.
>>
>> The "highway" key is about importance. The only category we have
>> full-stop made equivalent with a type of road design is "motorway".
>> From trunk on down, it is just different grades of importance. These
>> are how the definitions are listed on the 

Re: [Talk-us] Trunk

[Evin Fairchild]

To add onto what Bradley was saying about third-party applications, I just
want to add that I've done some fact-checking about a claim that Paul made
in a previous email about how Osmand renders trunks under the assumption
that they are expressways (to be clear, by this I mean divided highways w/
at-grade intersections). After some fact-checking, this claim receives a
truth rating of *completely FALSE*.

Anyway, I looked at how Osmand renders motorways versus trunk and I don't
know how it is that you, Paul, can say that trunk is assumed to be like an
expressway  in Osmand's render. That is simply not true. The motorway in
Osmand, for those who are unfamiliar, is red with a thin blue outline
around it, whereas trunk is just an orange-red line without any other color
outlining it. This makes it look more like a single-carriageway road and
less like an expressway like Paul falsely claims. All it looks like is a
road that is of higher-importance than primary, and does NOT at all look
like it could be an expressway. Usually, when maps show a divided highway
w/ at-grade intersections, it looks similar to a freeway, but a different
color, whereas an undivided two-lane road typically looks nothing like an
expressway or freeway. Thus, it is complete and utter lie to say that
Osmand makes the assumption that trunk roads are expressways. I don't know
how mkgmap shows trunk vs. motorway since I don't have a Garmin and thus
cannot test it out, but I don't trust that Paul is telling the truth here
either.

It's important to make truthful claims here, Paul; from now on, I will have
a VERY difficult time trusting anything you say. I know what I brought up
was kind of a side point, but I think it's important to call out BS when I
see it.

-Evin (compdude)


On Sat, Oct 14, 2017 at 10:23 AM, Bradley White 
wrote:

> > The concept of expressway and freeway are reasonably well known concepts;
> > it makes a lot of sense to map trunk and motorway to those concepts.
>
> I agree with freeways but not with expressways. I have no data to back
> this claim up, but I'm fairly convinced that, while the average
> citizen could easily differentiate between "freeway" and "not
> freeway", they would be hard pressed to do the same with an
> expressway. Anecdotal, but even when I spent time in the Santa Clara
> area which has a robust expressway system, I never heard a single
> person say "and then get on the expressway...", or even the word
> 'expressway' mentioned outside of it being the suffix of a road name.
> You're right that it's not a terribly difficult concept to understand
> and thus map, but I disagree that it's an important concept in
> explaining the road hierarchy in the US, so much so that we can equate
> an entire class of importance with them. We have a robust, clearly
> signposted freeway network in the US. We do not have the same with
> expressways. Roads tend to go in and out of "expressway" qualification
> depending on context, traffic levels of connecting roads, and highway
> budget & design policy. A road being built as an expressway is
> suggestive of its importance at best, and certainly not indicative.
>
> Edmonton has many roads around the east and west of the downtown area
> that are clearly built as expressways. However, they are only tagged
> secondary because, fundamentally, you only really need to use them to
> get around the immediate vicinity. Despite being very high quality
> roads, they aren't all that important in the grand scheme. I can point
> to many examples of urban roads that likely meet an expressway
> definition in my current home city of Reno, including one under
> construction. It would be absurd to me to tag them as being second in
> importance only to motorways just because they are well-built roads,
> because they're unimportant outside of getting around the relatively
> small Reno-Sparks metropolitan area.
>
> The "highway" key is about importance. The only category we have
> full-stop made equivalent with a type of road design is "motorway".
> From trunk on down, it is just different grades of importance. These
> are how the definitions are listed on the 'Key:highway' page, which I
> consider to be definitive. The fact that the words "trunk", "primary",
> "secondary", ... are used is an artifact of the UK roots of OSM. Had
> this project started in the US, the keys would probably be "freeway",
> "principal_artery", "major_artery", "minor_artery", "major_collector",
> ... leaving UK users scratching their heads trying to figure out how
> to adapt these definitions to their own network. In countries with
> signposted expressway systems, it is meaningful in understanding the
> road network to equate trunk with expressway, so they do that. I don't
> think doing the same is meaningful in the U.S. given how much
> variability and inconsistency there is with how and where expressways
> are constructed.
>
> > Even a lot of renderers make this same assumption:  mkgmap 

Re: [Talk-us] Trunk

[Bradley White]

> The concept of expressway and freeway are reasonably well known concepts;
> it makes a lot of sense to map trunk and motorway to those concepts.

I agree with freeways but not with expressways. I have no data to back
this claim up, but I'm fairly convinced that, while the average
citizen could easily differentiate between "freeway" and "not
freeway", they would be hard pressed to do the same with an
expressway. Anecdotal, but even when I spent time in the Santa Clara
area which has a robust expressway system, I never heard a single
person say "and then get on the expressway...", or even the word
'expressway' mentioned outside of it being the suffix of a road name.
You're right that it's not a terribly difficult concept to understand
and thus map, but I disagree that it's an important concept in
explaining the road hierarchy in the US, so much so that we can equate
an entire class of importance with them. We have a robust, clearly
signposted freeway network in the US. We do not have the same with
expressways. Roads tend to go in and out of "expressway" qualification
depending on context, traffic levels of connecting roads, and highway
budget & design policy. A road being built as an expressway is
suggestive of its importance at best, and certainly not indicative.

Edmonton has many roads around the east and west of the downtown area
that are clearly built as expressways. However, they are only tagged
secondary because, fundamentally, you only really need to use them to
get around the immediate vicinity. Despite being very high quality
roads, they aren't all that important in the grand scheme. I can point
to many examples of urban roads that likely meet an expressway
definition in my current home city of Reno, including one under
construction. It would be absurd to me to tag them as being second in
importance only to motorways just because they are well-built roads,
because they're unimportant outside of getting around the relatively
small Reno-Sparks metropolitan area.

The "highway" key is about importance. The only category we have
full-stop made equivalent with a type of road design is "motorway".
From trunk on down, it is just different grades of importance. These
are how the definitions are listed on the 'Key:highway' page, which I
consider to be definitive. The fact that the words "trunk", "primary",
"secondary", ... are used is an artifact of the UK roots of OSM. Had
this project started in the US, the keys would probably be "freeway",
"principal_artery", "major_artery", "minor_artery", "major_collector",
... leaving UK users scratching their heads trying to figure out how
to adapt these definitions to their own network. In countries with
signposted expressway systems, it is meaningful in understanding the
road network to equate trunk with expressway, so they do that. I don't
think doing the same is meaningful in the U.S. given how much
variability and inconsistency there is with how and where expressways
are constructed.

> Even a lot of renderers make this same assumption:  mkgmap maps trunk to
> Garmin's concept of expressway and motorway to freeway.  Osmand, easily the
> most popular data consumer for OpenStreetMap, makes the same assumption (to
> the point that most of it's map painting styles, the only differentiation
> between trunk and motorway is a color pallette shift).  It really wouldn't
> hurt the US community to have a "come to Jesus" moment on this,
> particularly when using the MUTCD definitions for expressway and freeway as
> qualifiers for trunk and freeway, makes this relatively easy.  The
> corollary to "don't tag for the renderer" is "don't break the renderer".
> Highways without access control being excluded from trunk or motorway isn't
> an intrinsically bad assumption to make.  Especially if we come to
> agreement on that, we can start having a productive talk on how to make
> carto not suck for Americans without breaking it for everyone else.

I'm really not that concerned with how third-party applications decide
to paint their roads. It's up to them to work with the data we
provide, not the other way around. If it is important to Garmin or
other applications to translate expressways, this can usually be
deduced from other tags, or we can trivially add an "expressway=" tag.
I also disagree that the carto in the US is bad, other than our
insistence that two-lane are categorically not trunk leaving
meaningless splatters of orange around the map at low zoom.

Also, apologies ahead of time if I keep breaking the archive
hierarchy, I'm not totally familiar with how to drive a mailing list
and I have yet to find a guide online that explains how.

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

Re: [OSM-talk-be] http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Walking_Routes

[joost schouppe]

Hi Stijn,

That is a huge page!

I would suggest splitting it in three:

- long distance routes

- walking node networks

- local routes



2017-10-03 20:20 GMT+02:00 Stijn Rombauts :

> Hello,
>
> Could it be that this page [1] has become too big, with too many links to
> relations? I hope you see what I see: from the 5th relation in the Nordic
> Walking table all relations are replaced by a Template:Relation.
> If so, what are we going to do about it? Split it up? In how many pages?
>
> Regards,
>
> StijnRR
>
> [1] http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/
> Walking_Routes#Nordic_Walking
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>


-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [OSM-talk] New OSM Quick-Fix service

[mmd]

Am 14.10.2017 um 11:33 schrieb Yuri Astrakhan:
> ** UPDATE: **
> 
> The service now supports "reject" button.  To use it, your query must
> contain "  #queryId:...  "  comment.  By default, when a user rejects
> something, a tag "_autoreject=id" is created. An object can have
> multiple rejected IDs. If the current query was previously rejected,
> user will no longer be able to edit the object with the same query.
> 
> Optionally, query may specify a different rejection tag with 
>  "  #rejectTag:...  ", instead of using the default "_autoreject".  I am
> still hoping for a better default name.
> 

How about creating a Wikidata entry for such a review result, and have
it point back to OSM via P402 (OpenStreetMap Relation identifier)?

Then there's only the question to create some new predicate P0815 to
store the result of an "OSM+Wikidata review", et voilà. Result available
for everyone via a public interface.

And you could easily extend it to other review apps such as osmose, by
adding even more such predicates P??? ("osmose review result", etc.).

This way we store such review data outside of OSM (where it doesn't
really belong), and everyone can benefit from it.


-- 




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

Re: [OSM-co] Abreviaturas - Consenso

[Jaime Mejia]

De acuerdo

Cordial Saludo,

Jaime Mejía

El 11 de octubre de 2017, 12:18, Jorge Aguirre 
escribió:

> Para terminar con este tema, quisiera pedir a la Comunidad de Talk-Co
> emitan su última palabra al respecto y podamos todos proceder de acuerdo a
> el consenso común:
>
>
> En su última respuesta, me baso en lo sugerido por *Andrés Gomez Casanova*
> - *"Por todo lo anterior, no considero apropiado ese cambio, y lo que si
> deberíamos hacer es poner los nombres completos de lo que esté en
> abreviatura. También se debería eliminar cualquier tag de Addr ya que eso
> corresponde a direcciones y no a calles.”*
>
>
> Con esta aunado a todas las anteriores respuestas, creo es seguro decir
> que todos *acordamos* con que la utilización de los nombres de las calles
> en su *forma abreviada NO DEBE SER UTILIZADO para nombrar las calles*,
> aunque así aparezcan físicamente en los rótulos de las mismas.
>
> Además, en los casos en los que ya se encuentre el nombre abreviado dentro
> de la casilla *addr:street*, todos deberán eliminarse debido a que ésta
> corresponde específicamente a las direcciones y no a los nombres de las
> calles.
>
> ¿Estamos todos de acuerdo con esto?
>
> Y muchas gracias a todos por aclararme este punto!
>
>
> Jorge Aguirre
> Geographer
> Kaart Group, LLC
> jo...@kaartgroup.com
> +(502) 4191 1999 
> www.kaartgroup.com
>
>
>
> *“Let's make our planet great again.”*
> - Emmanuel Macron
>   President of France
>
>
>
> 2017-10-10 23:09 GMT-06:00 :
>
>> Envíe los mensajes para la lista Talk-co a
>> talk-co@openstreetmap.org
>>
>> Para subscribirse o anular su subscripción a través de la WEB
>> https://lists.openstreetmap.org/listinfo/talk-co
>>
>> O por correo electrónico, enviando un mensaje con el texto "help" en
>> el asunto (subject) o en el cuerpo a:
>> talk-co-requ...@openstreetmap.org
>>
>> Puede contactar con el responsable de la lista escribiendo a:
>> talk-co-ow...@openstreetmap.org
>>
>> Si responde a algún contenido de este mensaje, por favor, edite la
>> linea del asunto (subject) para que el texto sea mas especifico que:
>> "Re: Contents of Talk-co digest...". Además, por favor, incluya en la
>> respuesta sólo aquellas partes del mensaje a las que está
>> respondiendo.
>>
>>
>> Asuntos del día:
>>
>>1. Re: Resumen de Talk-co, Vol 111, Envío 2 (Andres Gomez Casanova)
>>
>>
>> --
>>
>> Message: 1
>> Date: Wed, 11 Oct 2017 00:08:14 -0500
>> From: Andres Gomez Casanova 
>> To: OpenStreetMap Colombia 
>> Subject: Re: [OSM-co] Resumen de Talk-co, Vol 111, Envío 2
>> Message-ID: 
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hola de nuevo Jorge
>>
>> En general las abreviaciones no son buenas a nivel de datos / bases de
>> datos. Teniendo presente que OpenStreetMap es un gran conjunto de datos,
>> estos deben ser los más puros y simples posibles.
>>
>> Revisando el Wiki, en general no se recomiendan las abreviaciones, ya que
>> esta operación puede ser realizada por una máquina. Un algoritmo puede
>> convertir Carrera a Kr, Calle a Cl, Avenida a Av, fácilmente.
>> Además, escribir Carrera en un campo y Kr en otro, es en cierta forma
>> redundancia de datos, y no está ofreciendo más información, sino diferentes
>> formas de escribir lo mismo.
>> Con respecto a eso la sección Names del Wiki indica que no se debe usar
>> abreviaciones: https://wiki.openstreetmap.org
>> /wiki/Names#Abbreviation_.28don.27t_do_it.29 <
>> https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28d
>> on.27t_do_it.29>
>>
>> Si el sistema de abreviaciones es para un mecanismo como Nominatim, este
>> tiene unas tablas de correspondencia entre las posibles abreviaturas y sus
>> valores. Aquí se ven algunas de estas tablas:https://wiki.openstreet
>> map.org/wiki/Name_finder:Abbreviations > g/wiki/Name_finder:Abbreviations>
>> Si vas a crear un sistema que use los datos de OSM, entonces debes tener
>> algo similar, en vez de introducir más datos.
>>
>> Viendo un hilo de discusión de OSM en GitHub, veo que lonvia escribe lo
>> siguiente sobre short_name:
>> short_name should be a recognizable, commonly used short version of the
>> name, not a nick name (use alt_name for that) and not an abbreviation
>> (might go into ref, although that's a stretch, too) and it should certainly
>> be correct
>> Ahí se indica que ese tag no debe ser usado para abreviaciones.
>>
>> Finalmente, si se considerara aceptar esa abreviación, sería necesario
>> cambiar muchos datos en OSM. Algunos casos puede llegar a entrar en
>> colisión frente a algún uso que le hayan dado ya a short_name y sería aún
>> más complicado. También hay que decir que no es intuitivo poner el nombre
>> corto como abreviatura, por lo que las nuevas calles 

Re: [OSM-talk-fr] Publication OpenData du cadastre

[Frédéric Rodrigo]

Je me suis lancé dans l'extraction et la compilation thématique des 
couches de données. Dans le but d'avoir des données découpées par 
thématiques et non par feuilles cadastrales.


Je n'ai volontairement pris que l'habillage (pas de parcelle, bâtiment 
et numéro de rue).


Le résultat est disponible là :
http://osm110.openstreetmap.fr/~fred/cadastre-2017-07-06-edigeo/
et là
https://www.data.gouv.fr/fr/datasets/58e5924b88ee3802ca255566/

Pour la description du schéma de données voir la "Documentation du 
standard EDIGÉO" sur data.gouv.fr.


Ce sont des consolidations des données brutes, je n'ai fait aucun 
traitement dessus mis à part l'ajout du code insee pour connaître la 
commune d'origine.


Attention, les fichiers sont gros.
L'extraction conversion à pris 6.5j (on doit pouvoir faire plus rapide...)

Frédéric.


Le 03/10/2017 à 14:47, Christian Quest a écrit :

Oui, officiellement dispo depuis hier... :)

Les données brutes de la DGFiP sont au format EDIGEO, format peu 
courant mais ouvrable avec gdal (donc QGis).


Dans cette première livraison, Etalab propose une extraction des 
principales couches d'infos surfaciques remise au format geojson en 
WGS84: limites de communes, de section cadastrale, de parcelle, et 
l'emprise des bâtiments.


Des données sont téléchargeables par département et par communes pour 
les geojson et par département et feuille cadastrale pour l'EDIGEO.


Ces données seront mises à jour trimestriellement.


Les nouveautés à venir pour les contributeurs:

- la prochaine version de JOSM va pouvoir ouvrir directement les 
fichier EDIGEO de la DGFiP.
- l'extraction du bâti de cadastre.openstreetmap.fr 
 deviennent en partie inutiles
- les script d'extraction d'adresses de cadastre.openstreetmap.fr 
 et de BANO vont aussi pouvoir 
évoluer prochainement.


Il y a d'autres données provenant du cadastre qui seront bientôt 
disponibles:

- le PCI Image et  les localisants de parcelles
- l'historique des évolutions des parcelles (la parcelles XXX est 
séparée en YYY et ZZZ)



Les fichiers EDIGEO permettent bien plus que ce qu'on a pu faire 
jusqu'à maintenant. On a par exemple les dates de création et de 
dernière modification des objets.
On y trouve aussi des filaires portant les noms des voies pour 
l'habillage des plan... j'ai commencé à travailler dessus pour les 
rapprocher de FANTOIR, il se peut que ce type de traitement soit fait 
sur les données mises à disposition par Etalab en geojson.
D'autres traitements sont aussi envisagés par Etalab pour améliorer 
les données, les lier à d'autres, etc. Ceci devrait arriver d'ici la 
fin de l'année.


Etalab va aussi mettre en place des API pour interroger ces données, 
comme ça a pu être fait en mettant en place un géocodeur pour 
faciliter la réutilisation de la BAN.



Il mes semble utile qu'on réfléchisse ensemble au meilleur moyen 
d'exploiter ces données et surtout de le penser dans le long terme 
pour les mises à jour. Pour cela, évitons de nous précipiter sur des 
imports à partir de ces données pour l'instant très brutes.
Ces données font parti du "Service Public de la Donnée de Référence" 
dont le slogan est "Des données sur lesquelles vous pouvez compter"... 
c'est donc là pour longtemps ;)



Le 3 octobre 2017 à 14:20, David Marchal > a écrit :


Cher tous,


Je viens de voir que le cadastre, en tout cas certaines
informations, viennent d’être publiées en OpenData, et en
vectoriel, s’il vous plaît :

https://www.nextinpact.com/brief/le-cadastre-est-accessible-en-open-data-329.htm


 Sans
doute ce que Christian Quest disait être dans les tuyaux.
D’emblée, je vois l’utilisation du GeoJSON pour l’importation du
bâti, mais on doit pouvoir en tirer beaucoup plus. Merci à la
DGFiP et à Etalab pour ça, ça devrait nous aider.


Cordialement.


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





--
Christian Quest - OpenStreetMap France


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




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

hebdoOSM Nº 377 2017-10-03-2017-10-09

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 377 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/9535/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

hebdoOSM Nº 377 2017-10-03-2017-10-09

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 377 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/9535/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

hebdoOSM Nº 377 2017-10-03-2017-10-09

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 377 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/9535/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ht mailing list
Talk-ht@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ht
Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour 
traduire les messages.

[OSM-ja] 半鐘について

[ribbon]

https://www.openstreetmap.org/node/5167330035

なんですが、鉄塔の上に半鐘が付いています。
これ、どうタグ付けたらいいでしょうか。

一応 man_made=tower,tower_type=bell_tower にしています。

ribbon

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

Re: [OSM-talk] New OSM Quick-Fix service

[Jochen Topf]

Do I understand this correctly? You are creating tags in the OSM
database for your private tool? I hope there is some misunderstanding
here, because that isn't acceptable behaviour.

Jochen

On Sat, Oct 14, 2017 at 09:33:14AM +, Yuri Astrakhan wrote:
> Date: Sat, 14 Oct 2017 09:33:14 +
> From: Yuri Astrakhan 
> To: Simon Poole , talk@openstreetmap.org
> Subject: Re: [OSM-talk] New OSM Quick-Fix service
> 
> ** UPDATE: **
> 
> The service now supports "reject" button.  To use it, your query must
> contain "  #queryId:...  "  comment.  By default, when a user rejects
> something, a tag "_autoreject=id" is created. An object can have multiple
> rejected IDs. If the current query was previously rejected, user will no
> longer be able to edit the object with the same query.
> 
> Optionally, query may specify a different rejection tag with
>  "  #rejectTag:...  ", instead of using the default "_autoreject".  I am
> still hoping for a better default name.
> 
> Both #rejectTag and #queryId values must consist of only the Latin
> characters, digits, and underscores.
> 
> Additionally, the tool no longer allows editing above zoom 16.
> 
> Thanks!
> 
> 
> On Sat, Oct 14, 2017 at 12:34 AM Yuri Astrakhan 
> wrote:
> 
> > Simon, thanks for the constructive criticism, as it allows improvements
> > rather than aggravation. I propose that "rejections" are saved as a new
> > tag, for example "_autoreject".  In a way, this is very similar to the
> > "nobot" proposal - users reject a specific bot by hand.
> >
> > _autoreject will store a semicolon-separated multivalue tag.  A query will
> > contain some "ID", e.g. "amenity-sanatorium", and that ID will be added to
> > the _autoreject whenever user clicks "reject suggestion" button.
> >
> > Benefits:
> > * use existing tools to analyse, search, and edit this tag, without
> > creating anything new
> > * we can use it inside the queries themselves to say "only suggest to fix
> > X if the users have rejected Y", or if someone creates a bad query and most
> > values are rejected, we can easily find them and clean them up
> > * very easy to implement, few chances for bugs, no chances to loose
> > rejection data by accident
> > * other tools can also use this field to store rejections, e.g.
> > mapRoulette or Omose.
> > * Query authors can easily search for it to see why they showed up in the
> > query result, and fix the original query
> >
> > The biggest problem is the tag name, any suggestions?
> >

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


-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

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

[Talk-it] Risposta: Falegnameria / Segheria

[Lorenzo Mastrogiacomi]

Il giorno sab, 14/10/2017 alle 14.30 +0200, liste DOT girarsi AT posteo
DOT eu ha scritto:
> > 
> 
> In compenso nella wiki è un pò descritta:
> 
> http://wiki.openstreetmap.org/wiki/Tag:craft%3Dsawmill
> 
> 
> 

craft=sawmill è anche molto usato in effetti.
ed esiste anche industrial=sawmill come ha fatto notare Daniele.

Per il falegname c'è craft=joiner
https://wiki.openstreetmap.org/wiki/Tag%3Acraft%3Djoiner


Lorenzo___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Falegnameria / Segheria

[Alberto Nogaro]

>-Original Message-
>From: demon.box [mailto:e.rossin...@alice.it]
>Sent: sabato 14 ottobre 2017 09:54
>To: talk-it@openstreetmap.org
>Subject: [Talk-it] Falegnameria / Segheria
>
>ciao, scusate ma qual'è il tag corretto per una semplice falegnameria /
>segheria?
>
>craft=carpenter ?

Se l'attività è prevalentemente di segheria,  forse meglio questo:

https://wiki.openstreetmap.org/wiki/Tag:industrial%3Dsawmill

Ciao,
Alberto


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

Re: [Talk-it] Falegnameria / Segheria

[liste DOT girarsi AT posteo DOT eu]

Il 14/10/2017 13:54, Damjan Gerl ha scritto:

14.10.2017 - 12:57 - Volker Schmidt:

Che cosa intendi con "semplice segheria / falegnameria?

Per me sono due cose normalmente separate e distinte:
https://it.wikipedia.org/wiki/Segheria


La versione inglese di segheria e sawmill:
https://en.wikipedia.org/wiki/Sawmill

ma non la trovo usata in taginfo...



In compenso nella wiki è un pò descritta:

http://wiki.openstreetmap.org/wiki/Tag:craft%3Dsawmill



--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [Talk-it] Falegnameria / Segheria

[Daniele Forsi]

2017-10-14 13:54 GMT+02:00 Damjan Gerl:
> 14.10.2017 - 12:57 - Volker Schmidt:
>>
>> Che cosa intendi con "semplice segheria / falegnameria?
>>
>> Per me sono due cose normalmente separate e distinte:
>> https://it.wikipedia.org/wiki/Segheria
>
>
> La versione inglese di segheria e sawmill:
> https://en.wikipedia.org/wiki/Sawmill
>
> ma non la trovo usata in taginfo...

nel wiki c'è industrial=sawmill anche se ha solo una riga di descrizione:
"a place where logs are turned into wood products including lumber and plywood."
http://wiki.openstreetmap.org/wiki/Tag:industrial%3Dsawmill

-- 
Daniele Forsi

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

Re: [OSM-talk] New OSM Quick-Fix service

[Andy Townsend]

On 14/10/2017 12:06, Yuri Astrakhan wrote:

Andy, the query works fine, you probably hit it during the update.
That now produces a worldwide map showing where mappers have used a 
particular tag.  Except in the case of typing errors you shouldn't be 
changing tagX to tagY without any other knowledge without following 
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct (as 
noted many times by many people previously).


As an aside, based on what I'm worried that you're trying to do, the UI 
is absolutely garbage.  I see buttons that do things like "Add variable 
containing entity label"(whatever that means) and a "Filter" button that 
adds a dropbox with no items in it.  It's likely that many people trying 
to use this will make edits by mistake.


  Also, I just updated some queries at Quick_fixes 
 - they now able to 
record when change should be rejected.  The IP address has been 
unchanged ever since I announced the OSM+Wikidata service.

But who knows what it is?  It doesn't even support https!

Regards,
Andy

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

Re: [Talk-it] Falegnameria / Segheria

[Damjan Gerl]

14.10.2017 - 12:57 - Volker Schmidt:

Che cosa intendi con "semplice segheria / falegnameria?

Per me sono due cose normalmente separate e distinte:
https://it.wikipedia.org/wiki/Segheria


La versione inglese di segheria e sawmill:
https://en.wikipedia.org/wiki/Sawmill

ma non la trovo usata in taginfo...

https://it.wikipedia.org/wiki/Carpentiere oppure 
https://it.wikipedia.org/wiki/Falegname


woodworking è molto generico:
https://en.wikipedia.org/wiki/Woodworking


Damjan

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

Re: [Talk-it] Falegnameria / Segheria

[demon.box]

Certo che sono 2 cose ben diverse.
Nel mio caso per falegnameria intendo dove con il legno si fabbrica qualcosa
ad es. mobili.
Per segheria intendo invece dove si lavorano i tronchi grezzi per ricavarne
travi, assi, ecc. che poi verranno utilzzate in edilizia piuttosto che da un
falegname.
Grazie ciao.
--enrico




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-talk] New OSM Quick-Fix service

[Yuri Astrakhan]

Andy, the query works fine, you probably hit it during the update.  Also, I
just updated some queries at Quick_fixes
 - they now able to record
when change should be rejected.  The IP address has been unchanged ever
since I announced the OSM+Wikidata service.

Christoph, I looked around Osmose and MapRoulette, and I don't see any such
warnings . Could you elaborate how you would like these kinds of tools to
promote good editing practices? Any UI ideas? I'll be happy to improve our
tools on making sure they meet community expectations.

On Sat, Oct 14, 2017 at 6:09 AM Christoph Hormann  wrote:

> On Friday 13 October 2017, Yuri Astrakhan wrote:
> > I would like to introduce a new quick-fix editing service.  It allows
> > users to generate a list of editing suggestions using a query, review
> > each suggestion one by one, and click "Save" on each change if they
> > think it's a good edit.
>
> This is a tool to perform automated edits as per the automated edits
> policy.  A resposible developer of such a tool should inform its users
> that making automated edits comes with certain requirements and that
> not following these rules can result in changes being reverted and user
> accounts being blocked.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Falegnameria / Segheria

[Volker Schmidt]

Che cosa intendi con "semplice segheria / falegnameria?

Per me sono due cose normalmente separate e distinte:
https://it.wikipedia.org/wiki/Segheria
https://it.wikipedia.org/wiki/Carpentiere oppure
https://it.wikipedia.org/wiki/Falegname

woodworking è molto generico:
https://en.wikipedia.org/wiki/Woodworking
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-se] Cykelbanor och avtagsvägar

[Ture Pålsson]

Jag skulle sätta det första alternativet,  men kan egentligen inte argumentera 
för det. Path är oftast spontanstigar, om man tittar på existerande data, iaf i 
mina trakter.

 Originalmeddelande 
Från: Karl-Johan Karlsson  
Datum: 2017-10-14  12:07  (GMT+01:00) 
Till: OpenStreetMap Sverige mailinglista  
Rubrik: Re: [Talk-se] Cykelbanor och avtagsvägar 

Jag är nog inne på samma linje som ni d.v.s. att behålla cykelbanan som en 
separat väg, så då gör jag så att jag förlänger anslutningsvägen och markerar 
förlängningen med som cykelväg.

När vi ändå är inne på det. Använder ni "highway=cycleway foot=designated" 
eller "highway=path bicycle=designated foot=designated" för cykelbanor där även 
gångtrafikanter är tillåtna?

 
Den 14 oktober 2017 11:25 skrev Erik Lundin :


Den 2017-10-14 kl. 11:19, skrev Ture Pålsson:


Eftersom det är en kantsten mellan cykelbanan och vägen tycker jag det känns 
vettigt att behålla cykelbanan som en separat way i OSM — en sådan där kantsten 
är ju inget man korsar hur som helst, utan det kräver lite planering och 
manövrerande.




Om man kopplar ihop vägarna med en highway=cycleway så kan man ju lägga in en 
nod med barrier=kerb på anslutningssträckan.



/Erik



___

Talk-se mailing list

Talk-se@openstreetmap.org

https://lists.openstreetmap.org/listinfo/talk-se



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

Re: [Talk-se] Cykelbanor och avtagsvägar

[M Branting]

Rita in en kort anslutning mellan c-banan och vägen där svängen ska kunma göras

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

Re: [Talk-se] Cykelbanor och avtagsvägar

[Karl-Johan Karlsson]

Jag är nog inne på samma linje som ni d.v.s. att behålla cykelbanan som en
separat väg, så då gör jag så att jag förlänger anslutningsvägen och
markerar förlängningen med som cykelväg.

När vi ändå är inne på det. Använder ni "highway=cycleway foot=designated"
eller "highway=path bicycle=designated foot=designated" för cykelbanor där
även gångtrafikanter är tillåtna?

Den 14 oktober 2017 11:25 skrev Erik Lundin :

>
> Den 2017-10-14 kl. 11:19, skrev Ture Pålsson:
>
>> Eftersom det är en kantsten mellan cykelbanan och vägen tycker jag det
>> känns vettigt att behålla cykelbanan som en separat way i OSM — en sådan
>> där kantsten är ju inget man korsar hur som helst, utan det kräver lite
>> planering och manövrerande.
>>
>
> Om man kopplar ihop vägarna med en highway=cycleway så kan man ju lägga in
> en nod med barrier=kerb på anslutningssträckan.
>
> /Erik
>
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [OSM-talk] New OSM Quick-Fix service

[Christoph Hormann]

On Friday 13 October 2017, Yuri Astrakhan wrote:
> I would like to introduce a new quick-fix editing service.  It allows
> users to generate a list of editing suggestions using a query, review
> each suggestion one by one, and click "Save" on each change if they
> think it's a good edit.

This is a tool to perform automated edits as per the automated edits 
policy.  A resposible developer of such a tool should inform its users 
that making automated edits comes with certain requirements and that 
not following these rules can result in changes being reverted and user 
accounts being blocked.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-it] Ultimo tratto relazione Alpinistica

[Volker Schmidt]

Il sac_scale  va messo
sul way individuale e può variare da pezzo a pezzo del sentiero.
Il tag cai_scale
 (ancora in
fase di proposta) si applica al sentiero nella sua totalità (e solo in
Italia). Quindi andrebbe sulla relazione e non sui ways individuali che
compongono il sentiero.
Nel tuo caso, dove c'è una parte del sentiero che è più facile ed una,
successiva, più impegnativa, si potrebbe pensare a due relazioni raccolti
in una super-relazione, mettendo valori di cai_scale diversi sulle due
relazioni.
Il tag ref contiene sempre il numero del sentiero, cioè il sentiero SATxyz
o CAIxyz o AVSxyz il valore numerico "xyz". In casi dove non c'è numero, ma
una lettera o una combinazione di lettera e numero riporti questi.



2017-10-14 10:28 GMT+02:00 Cascafico Giovanni :

> Direi di no: la difficoltà per chi intraprende il percorso della
> relazione  é sempre quella del tratto peggiore è il viaggiatore é meglio lo
> sappia.
>
> Se hai info dettagliate, assegna i relativi tag alle way, spezzandole
> all'occorrenza.
>
> Il 14/ott/2017 08:57, "angelo mornata"  ha
> scritto:
>
>> In una Relazione, quando l'ultimo tratto è alpinistico va Divisa, e fatta
>> una relazione a parte per il suddetto tratto?
>>
>> Esempio: Partenza, arrivo al bivacco una relazione, bivacco cima un'altra
>> relazione?
>>
>>
>> Che Ref va messo su una via Alpinistica?
>>
>>
>> Grazie e scusate l'ignoranza
>>
>>
>> Angelo
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-be] Réunion OSM à Arlon - OSM Meeting in Arlon - 24 October 2017 at 19.30

[Jonathan Beliën]

Done !

Published on Meetup : 
https://www.meetup.com/OpenStreetMap-Belgium/events/244198136/

Published on OSMBE calendar : http://www.osm.be/calendar.html
Published on Maptime Belgium : 
http://maptime.io/belgium/event/2017/10/24/meeting-arlon/


I put the "default" description ! Pierre, if you want me to change it, 
just send me the description you want :)


And thank you very much Pierre for organizing this meetup !



Jonathan

Le 14-10-17 à 11:18, joost schouppe a écrit :

This is great!

Would you mind adding it to the Meetup calender? (or I can do it for you)

Op 13 okt. 2017 6:37 p.m. schreef "Pierre Parmentier" 
>:


To the OSM Mappers of the Luxembourg province and around,

We shall meet on Tuesday 24 October 2017 at 19.30 in Arlon.
Already 4 subscribed! WiFi available.
Meeting at the taverne Les Arcades, place Léopold 5.

--

Salut à tous les cartographes OSM de la province de Luxembourg et
alentour,

Mardi 24 octobre 2017, à 19.30 h, réunion à Arlon.
Déjà 4 inscrits ! WiFi disponible.
Rendez-vous à la taverne Les Arcades, place Léopold 5.

Pierre P. /// foxandpotatoes

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




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


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

Re: [OSM-talk] New OSM Quick-Fix service

[Yuri Astrakhan]

** UPDATE: **

The service now supports "reject" button.  To use it, your query must
contain "  #queryId:...  "  comment.  By default, when a user rejects
something, a tag "_autoreject=id" is created. An object can have multiple
rejected IDs. If the current query was previously rejected, user will no
longer be able to edit the object with the same query.

Optionally, query may specify a different rejection tag with
 "  #rejectTag:...  ", instead of using the default "_autoreject".  I am
still hoping for a better default name.

Both #rejectTag and #queryId values must consist of only the Latin
characters, digits, and underscores.

Additionally, the tool no longer allows editing above zoom 16.

Thanks!


On Sat, Oct 14, 2017 at 12:34 AM Yuri Astrakhan 
wrote:

> Simon, thanks for the constructive criticism, as it allows improvements
> rather than aggravation. I propose that "rejections" are saved as a new
> tag, for example "_autoreject".  In a way, this is very similar to the
> "nobot" proposal - users reject a specific bot by hand.
>
> _autoreject will store a semicolon-separated multivalue tag.  A query will
> contain some "ID", e.g. "amenity-sanatorium", and that ID will be added to
> the _autoreject whenever user clicks "reject suggestion" button.
>
> Benefits:
> * use existing tools to analyse, search, and edit this tag, without
> creating anything new
> * we can use it inside the queries themselves to say "only suggest to fix
> X if the users have rejected Y", or if someone creates a bad query and most
> values are rejected, we can easily find them and clean them up
> * very easy to implement, few chances for bugs, no chances to loose
> rejection data by accident
> * other tools can also use this field to store rejections, e.g.
> mapRoulette or Omose.
> * Query authors can easily search for it to see why they showed up in the
> query result, and fix the original query
>
> The biggest problem is the tag name, any suggestions?
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

[Yuri Astrakhan]

Hi Michael,

Currently, the tool creates two changeset tags:

  created_by=OSM+Wikidata 0.1
  comment=(generated by the user's query)

What other tags should I add?  I know the name is not very good, and I
should finalize with it soon to reduce confusion.  Also, I just bumped the
version to 0.2, and added the ability to do reject tag (as described in my
prev email).

Thanks!

On Sat, Oct 14, 2017 at 3:45 AM Michael Reichert 
wrote:

> Hi Yuri,
>
> Am 2017-10-13 um 23:25 schrieb Yuri Astrakhan:
> > I would like to introduce a new quick-fix editing service.  It allows
> users
> > to generate a list of editing suggestions using a query, review each
> > suggestion one by one, and click "Save" on each change if they think
> it's a
> > good edit.
> >
> > For example, RU community wants to convert  amenity=sanatorium  ->
> > leisure=resort + resort=sanatorium.  Clicking on a dot shows a popup with
> > the suggested edit. If you think the edit is correct, simply click Save.
> > Try it:  http://tinyurl.com/y8mzvk84
> >
> > I have started a Quick fixes wiki page, where we can share and discuss
> > quick fix ideas.
> > * Quick fixes 
> > * Documentation
> > <
> https://wiki.openstreetmap.org/wiki/Wikidata%2BOSM_SPARQL_query_service#Quick-fix_Editor
> >
>
> Which created_by=* tag does your editor set on the changesets?
>
> Best regards
>
> Michael
>
>
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-se] Cykelbanor och avtagsvägar

[Erik Lundin]

Den 2017-10-14 kl. 11:19, skrev Ture Pålsson:

Eftersom det är en kantsten mellan cykelbanan och vägen tycker jag det känns 
vettigt att behålla cykelbanan som en separat way i OSM — en sådan där kantsten 
är ju inget man korsar hur som helst, utan det kräver lite planering och 
manövrerande.


Om man kopplar ihop vägarna med en highway=cycleway så kan man ju lägga 
in en nod med barrier=kerb på anslutningssträckan.


/Erik

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

Re: [Talk-se] Cykelbanor och avtagsvägar

[Ture Pålsson]

> 14 okt. 2017 kl. 10:36 skrev Karl-Johan Karlsson 
> :
> 
> https://www.mapillary.com/app?focus=photo=ZpwBuV8oAsm-mSHwiJmh4g
> [ … ]
> Hur bör detta ritas om (modelleras) i openstreetmap? Är det bara de få 
> metrarna där kanten är nedfasad som ska markeras på något speciellt vis eller 
> ska hela cykelbanan slås samman med bilvägen?
> Det f[…]

Eftersom det är en kantsten mellan cykelbanan och vägen tycker jag det känns 
vettigt att behålla cykelbanan som en separat way i OSM — en sådan där kantsten 
är ju inget man korsar hur som helst, utan det kräver lite planering och 
manövrerande.

För att få ihop routingen i korsningen skulle jag nog vara frestad att helt 
enkelt förlänga den way som representerar avtagsvägen några meter så att den 
når fram till cykelbanan också. Ev. är det kanske snyggast att tagga den ligga 
förlängningen highway=cycleway.
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [OSM-talk-be] Réunion OSM à Arlon - OSM Meeting in Arlon - 24 October 2017 at 19.30

[joost schouppe]

This is great!

Would you mind adding it to the Meetup calender? (or I can do it for you)

Op 13 okt. 2017 6:37 p.m. schreef "Pierre Parmentier" <
pierrecparment...@gmail.com>:

> To the OSM Mappers of the Luxembourg province and around,
>
> We shall meet on Tuesday 24 October 2017 at 19.30 in Arlon.
> Already 4 subscribed! WiFi available.
> Meeting at the taverne Les Arcades, place Léopold 5.
>
> --
>
> Salut à tous les cartographes OSM de la province de Luxembourg et alentour,
>
> Mardi 24 octobre 2017, à 19.30 h, réunion à Arlon.
> Déjà 4 inscrits ! WiFi disponible.
> Rendez-vous à la taverne Les Arcades, place Léopold 5.
>
> Pierre P. /// foxandpotatoes
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-se] Cykelbanor och avtagsvägar

[Erik Lundin]

Den 2017-10-14 kl. 10:36, skrev Karl-Johan Karlsson:
Hur bör detta ritas om (modelleras) i openstreetmap? Är det bara de få 
metrarna där kanten är nedfasad som ska markeras på något speciellt vis 
eller ska hela cykelbanan slås samman med bilvägen?


Ja, det där känns ju som ett ganska vanligt fall men jag vet inte om det 
finns nåt rekommenderat sätt att göra på. Själv skulle jag rösta för att 
rita in en kort väg från cykelbanan till noden där vägarna möts och 
tagga den på samma sätt som cykelbanor brukar taggas 
(bicycle=designated). Rent topologiskt känns det rätt i alla fall.


/Erik

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

Re: [OSM-talk-be] Réunion OSM à Arlon - OSM Meeting in Arlon - 24 October 2017 at 19.30

[Jonathan Beliën]

Good morning Pierre,

Do you want me to publish your meetup on our Meetup page : 
https://www.meetup.com/OpenStreetMap-Belgium/ ?


I'll also publish it in OpenStreetMap Belgium calendar : 
http://www.osm.be/calendar.html


Wish you a pleasant weekend !


Jonathan


Le 13-10-17 à 18:36, Pierre Parmentier a écrit :

To the OSM Mappers of the Luxembourg province and around,

We shall meet on Tuesday 24 October 2017 at 19.30 in Arlon.
Already 4 subscribed! WiFi available.
Meeting at the taverne Les Arcades, place Léopold 5.

--

Salut à tous les cartographes OSM de la province de Luxembourg et 
alentour,


Mardi 24 octobre 2017, à 19.30 h, réunion à Arlon.
Déjà 4 inscrits ! WiFi disponible.
Rendez-vous à la taverne Les Arcades, place Léopold 5.

Pierre P. /// foxandpotatoes


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


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

Re: [Talk-it] Falegnameria / Segheria

[liste DOT girarsi AT posteo DOT eu]

Il 14/10/2017 10:37, demon.box ha scritto:

nel frattempo ho trovato

craft=joiner

http://wiki.openstreetmap.org/wiki/Tag:craft=joiner

che va sicuramente bene per la falegnameria ma invece un segheria non è
esattamente la stessa cosa...

che dite?

grazie

--enrico



Ho cercato la pura traduzione con il traduttore automatico, e risulta 
woodworking, per cui attraverso questo valore ho trovato questo su taginfo:


https://taginfo.openstreetmap.org/tags/craft=woodworking

Sono solo 10 istanze, c'è anche industrial=woodworking con 7 istanze.

Io, visto si tratta di lavorazione grezza, punterei su 
man_made=woodworking, coprendo l'area, craft mi sà più da piccole 
falegnamerie tipo negozio.


industrial=woodworking lo userei per lavorazioni di grossa portata 
insieme a landuse=industrial, anche se quest'ultimo si usa per zone 
artigianali.



--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

[OSM-talk-fr] Certificat Osmose expiré

[Francois Gouget]

Le certificat de https://osmose.openstreetmap.fr/ a expiré aujourd'hui 
à 00:15 :

osmose.openstreetmap.fr uses an invalid security certificate.

The certificate expired on 14/10/2017 00:15. The current time is 
14/10/2017 10:39.

Error code: SEC_ERROR_EXPIRED_CERTIFICATE


Quelqu'un peut-il jeter un oeil ?


-- 
Francois Gouget   http://fgouget.free.fr/
   If it stinks, it's chemistry. If it moves, it's biology.
  If it does not work, it's computer science.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Falegnameria / Segheria

[demon.box]

nel frattempo ho trovato

craft=joiner

http://wiki.openstreetmap.org/wiki/Tag:craft=joiner

che va sicuramente bene per la falegnameria ma invece un segheria non è
esattamente la stessa cosa...

che dite?

grazie

--enrico




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

[Talk-se] Cykelbanor och avtagsvägar

[Karl-Johan Karlsson]

https://www.mapillary.com/app?focus=photo=ZpwBuV8oAsm-mSHwiJmh4g

Vad man ser på denna Mapillary bild är alltså en cykelbana. Vad som kanske
inte framgår tydligt på bilden är att det är en stensatt kant på ca 10 cm
ner till vägen, men eftersom det är en avtagsväg till vänster på bilden
(som det är tänkt att cyklister ska kunna cykla in på) så är kanten
nedfasad i några meter.

Idag är denna cykelbana, i openstreetmap, helt separat och har ingen
koppling till själva bilvägen. Detta får till följd att program som
beräknar rutter för cykling (t.ex. https://openrouteservice.org) inte tror
att det för en cyklist går att cykla in på den där avtagsvägen.

Hur bör detta ritas om (modelleras) i openstreetmap? Är det bara de få
metrarna där kanten är nedfasad som ska markeras på något speciellt vis
eller ska hela cykelbanan slås samman med bilvägen?
Det finns en mängd alternativ (se länken nedan), men jag är inte säker på
vilket av dessa som känns som det bästa alternativet för svenska cykelbanor.

https://wiki.openstreetmap.org/wiki/Bicycle#Bicycle_Restrictions

Vad tycker ni?
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-it] Ultimo tratto relazione Alpinistica

[Cascafico Giovanni]

Direi di no: la difficoltà per chi intraprende il percorso della relazione
é sempre quella del tratto peggiore è il viaggiatore é meglio lo sappia.

Se hai info dettagliate, assegna i relativi tag alle way, spezzandole
all'occorrenza.

Il 14/ott/2017 08:57, "angelo mornata"  ha
scritto:

> In una Relazione, quando l'ultimo tratto è alpinistico va Divisa, e fatta
> una relazione a parte per il suddetto tratto?
>
> Esempio: Partenza, arrivo al bivacco una relazione, bivacco cima un'altra
> relazione?
>
>
> Che Ref va messo su una via Alpinistica?
>
>
> Grazie e scusate l'ignoranza
>
>
> Angelo
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] Falegnameria / Segheria

[demon.box]

ciao, scusate ma qual'è il tag corretto per una semplice falegnameria /
segheria?

craft=carpenter ?

http://wiki.openstreetmap.org/wiki/Tag:craft%3Dcarpenter

...non mi sembra esattamente quello giusto.

grazie

--enrico




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-talk] New OSM Quick-Fix service

[Michael Reichert]

Hi Yuri,

Am 2017-10-13 um 23:25 schrieb Yuri Astrakhan:
> I would like to introduce a new quick-fix editing service.  It allows users
> to generate a list of editing suggestions using a query, review each
> suggestion one by one, and click "Save" on each change if they think it's a
> good edit.
> 
> For example, RU community wants to convert  amenity=sanatorium  ->
> leisure=resort + resort=sanatorium.  Clicking on a dot shows a popup with
> the suggested edit. If you think the edit is correct, simply click Save.
> Try it:  http://tinyurl.com/y8mzvk84
> 
> I have started a Quick fixes wiki page, where we can share and discuss
> quick fix ideas.
> * Quick fixes 
> * Documentation
> 

Which created_by=* tag does your editor set on the changesets?

Best regards

Michael




-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-it] Ultimo tratto relazione Alpinistica

[angelo mornata]

In una Relazione, quando l'ultimo tratto è alpinistico va Divisa, e fatta una 
relazione a parte per il suddetto tratto?

Esempio: Partenza, arrivo al bivacco una relazione, bivacco cima un'altra 
relazione?


Che Ref va messo su una via Alpinistica?


Grazie e scusate l'ignoranza


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