Re: [OSM-talk] Craigslist OpenStreetMap Rendering Issue

2015-06-01 Thread Bryce Nesbitt

 The tag oneway=true is extinct in the database.


Without defending the author of the Craigslist stylesheet: tracking OSM
data changes is hard.

In part due to the negative attitude towards cleanup mechanical edits, the
data is all over the place.
1, -1, reverse, true, false, no, yes, maybe.  Aghgh.  Stuff gets deprecated
then rots in place for weeks
months years.

How could a rendering engine keep up with all the positive and negative
terms people dream up,
wikifi, and then use inconsistently?

-

Mechanical edits help data consumers.  Clear tag descriptions help data
consumers and mappers.
Editor validations helps data consumers, and it's rather weak right now.
API level rejection of certain
edit patterns would help even more.

A clear migration path between tagging schemes would help data consumers a
lot.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Craigslist OpenStreetMap Rendering Issue

2015-06-01 Thread Marc Gemis
just a few thoughts:

What is the value of a 1 time mechanical edit cleanup ? From the moment you
ran your script, new data can arrive in the OSM with the wrong values.
Will you run your script daily ? What if a data consumer obtains the data
between 2 runs of your script ?

Wouldn't it be better to properly inform the data consumer about the
existence of some fix scripts that can be run after obtaining the data
from OSM ?

Of course one could imaging an OSM setup where those mechanical edits would
run automatically after each submission, but that is out of the question I
think. Part of that work could be (or is) done by the validators in the
editors.

regards

m



On Mon, Jun 1, 2015 at 8:36 AM, Bryce Nesbitt bry...@obviously.com wrote:

 The tag oneway=true is extinct in the database.


 Without defending the author of the Craigslist stylesheet: tracking OSM
 data changes is hard.

 In part due to the negative attitude towards cleanup mechanical edits, the
 data is all over the place.
 1, -1, reverse, true, false, no, yes, maybe.  Aghgh.  Stuff gets
 deprecated then rots in place for weeks
 months years.

 How could a rendering engine keep up with all the positive and negative
 terms people dream up,
 wikifi, and then use inconsistently?

 -

 Mechanical edits help data consumers.  Clear tag descriptions help data
 consumers and mappers.
 Editor validations helps data consumers, and it's rather weak right now.
 API level rejection of certain
 edit patterns would help even more.

 A clear migration path between tagging schemes would help data consumers a
 lot.

 ___
 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: [OSM-talk] Craigslist OpenStreetMap Rendering Issue

2015-06-01 Thread Martin Koppenhoefer
2015-06-01 9:55 GMT+02:00 Marc Gemis marc.ge...@gmail.com:

 Part of that work could be (or is) done by the validators in the editors.



+1
If you look at the actual values for oneway, very few are obviously
mistagged, e.g. oneway=yes;no (32) and no;yes (111) - these result very
likely from merging streets with different properties. I have tested this
with current JOSM, if you combine a way with oneway=yes and one with
oneway=no you will get to a window which asks to choose from yes, no,
/none/, /all/ and you have to deliberately choose all to get an
ambiguous value. iD is working similarly, but it doesn't let you decide, it
automatically creates a double value (yes;no), and the direction is taken
from the first way selected (e.g. 1st way selected is oneway=no and 2nd way
is oneway=yes and pointing in the opposite direction will revert the
direction of the oneway=yes way without notice and will create a oneway
value of no;yes also without notice. I have opened a ticket for this
behaviour: https://github.com/openstreetmap/iD/issues/2670  )

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


Re: [OSM-talk] Craigslist OpenStreetMap Rendering Issue

2015-06-01 Thread Bryce Nesbitt
On Mon, Jun 1, 2015 at 12:55 AM, Marc Gemis marc.ge...@gmail.com wrote:

 just a few thoughts:

 What is the value of a 1 time mechanical edit cleanup ? From the moment
 you ran your script, new data can arrive in the OSM with the wrong values.
 Will you run your script daily ? What if a data consumer obtains the data
 between 2 runs of your script ?


In my experience, two rounds of mechanical edit are sufficient.
The first gets the bulk of the problem, and generally shifts the mapping
behavior as well.
Then maybe a few weeks later check if anyone is using the old tags and
reach out to them via private message.

The value of a 1 time edit is high, as long as there is sufficient
consensus or apathy about the change.



*The potential for data consumer impact seems highly overrated on this
mailing list.  *By the time something is mechanically edited data consumers
have generally moved on.  See also
http://wiki.openstreetmap.org/wiki/Deprecated_features

For example take amenity=dog_bin.  That's a minor tag, and chances are
any data consumer also processes
amenity=dog_waste_bin.  Thus retagging dog_bin - dog_waste_bin would
have *zero data consumer impact no matter when the script is run.*


---
The tag migration is not the issue really.  The problem comes in when the
old tag was semantically unclear and can't be migrated.
I ran into that with excrement tags actually: one set of excrement tags was
used for *four distinct features* and to clean that up I had to look
carefully at
the context and/or ask a local mapper to verify on the ground.  Fortunately
the context made the right tag clear in most of the cases: but it could
have been really hard.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Craigslist OpenStreetMap Rendering Issue

2015-06-01 Thread Toby Murray
Yeah, I noticed this about the Craigslist rendering a while ago. In my case
it was ways tagged as oneway=-1. Since the ways were not members of any
relations and there was no other reason for them to be tagged this way, I
reversed the way directions and changed the tag to oneway=yes but obviously
this doesn't apply to the situation that started this thread.

FYI: last time I checked, Craigslist also had random problems rendering
water. Some lakes just don't show up in their map even though they are
tagged correctly and don't have any tricky geometry. This has generated
more than a few notes. I made a comment about this in the map feedback
forum and one of their devs hopped on to IRC the next day and said that
they were aware of it but hadn't figured out what the problem was.

Toby


On Mon, Jun 1, 2015 at 4:35 AM, Martin Koppenhoefer dieterdre...@gmail.com
wrote:


 2015-06-01 9:55 GMT+02:00 Marc Gemis marc.ge...@gmail.com:

 Part of that work could be (or is) done by the validators in the editors.



 +1
 If you look at the actual values for oneway, very few are obviously
 mistagged, e.g. oneway=yes;no (32) and no;yes (111) - these result very
 likely from merging streets with different properties. I have tested this
 with current JOSM, if you combine a way with oneway=yes and one with
 oneway=no you will get to a window which asks to choose from yes, no,
 /none/, /all/ and you have to deliberately choose all to get an
 ambiguous value. iD is working similarly, but it doesn't let you decide, it
 automatically creates a double value (yes;no), and the direction is taken
 from the first way selected (e.g. 1st way selected is oneway=no and 2nd way
 is oneway=yes and pointing in the opposite direction will revert the
 direction of the oneway=yes way without notice and will create a oneway
 value of no;yes also without notice. I have opened a ticket for this
 behaviour: https://github.com/openstreetmap/iD/issues/2670  )

 cheers,
 Martin

 ___
 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: [OSM-talk] Craigslist OpenStreetMap Rendering Issue

2015-05-31 Thread John Eldredge
Yes, I would class this as a rendering error on Craigslist's part, not a 
data error on OSM's part. It sounds like the code is checking for the 
presence of the oneway tag, where it should be checking for the presence of 
oneway=yes.


--
John F. Eldredge -- j...@jfeldredge.com
Darkness cannot drive out darkness; only light can do that. Hate cannot 
drive out hate; only love can do that. -- Martin Luther King, Jr.




On May 31, 2015 2:05:06 AM Bryce Nesbitt bry...@obviously.com wrote:


After a long stretch of oneway=yes, I might indeed tag oneway=no
just to keep someone from assuming I'd made a mistake.  oneway=no is a
declaration,
as opposed to a lack of information.



--
___
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: [OSM-talk] Craigslist OpenStreetMap Rendering Issue

2015-05-31 Thread Warin

On 1/06/2015 6:42 AM, John Eldredge wrote:


Yes, I would class this as a rendering error on Craigslist's part, not 
a data error on OSM's part. It sounds like the code is checking for 
the presence of the oneway tag, where it should be checking for the 
presence of oneway=yes.




Or oneway=1, -1 reverse, true, reversible


On May 31, 2015 2:05:06 AM Bryce Nesbitt bry...@obviously.com wrote:


After a long stretch of oneway=yes, I might indeed tag oneway=no
just to keep someone from assuming I'd made a mistake.  oneway=no is 
a declaration,

as opposed to a lack of information.



Is not the note= key to be used for passing that kind of information to 
other mappers? To me the note= key is much more indicative to fellow 
mappers than a value in another key.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Craigslist OpenStreetMap Rendering Issue

2015-05-31 Thread Andrew Hain
Warin 61sundowner at gmail.com writes:

 Or oneway=1, -1 reverse, true, 
reversible 

The tag oneway=true is extinct in the 
database.

--
Andrew




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


Re: [OSM-talk] Craigslist OpenStreetMap Rendering Issue

2015-05-31 Thread Bryce Nesbitt
After a long stretch of oneway=yes, I might indeed tag oneway=no
just to keep someone from assuming I'd made a mistake.  oneway=no is a
declaration,
as opposed to a lack of information.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Craigslist OpenStreetMap Rendering Issue

2015-05-31 Thread Philip Barnes
On Sun, 2015-05-31 at 07:56 +0200, Marc Gemis wrote:
 I've seen this topic being discussed here or elsewhere in the past. I
 thought that the consensus was that in some area's (a Spanish town I
 believe), it was ok to leave the oneway=no. The reasoning was that
 most streets in that town were oneway=yes, and the oneway=no was used
 to indicate that this road was surveyed and and an exception to the
 oneway=yes.
 
 
 so a world-wide mechanical edit should not be performed.
 
+1

iD does prompt users to fill in tags such as oneway=no, horse=yes on
roads and does I think lead new mappers to believe that such tags are
required. Whilst I sometimes remove these as part of an edit, a
mechanical edit would be wrong for the reasons stated above.

Phil (trigpoint)



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


Re: [OSM-talk] Craigslist OpenStreetMap Rendering Issue

2015-05-31 Thread Lester Caine
Forgot reply to list :(

On 31/05/15 01:51, Mike Thompson wrote:
 Why care? I would imagine to the majority of the users make no
 distinction between OpenStreetMap and Craigslist's rendering of
 OpenStreetMap, if the map is wrong, to them that simply means that
 OpenStreetMap is wrong.

There are a number of reasons why oneway=no is a valid tag, so if the
renderer is simply reading 'oneway' and ignoring the =no one has to ask
the question how many other similar tags are also being incorrectly
handled. In this case Craigslist is simply wrong and there is nothing
openstreetmap can do about that ... or would want to do about it on the
data!

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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


Re: [OSM-talk] Craigslist OpenStreetMap Rendering Issue

2015-05-31 Thread Andrew Hain
Mike Thompson miketho16 at gmail.com writes:

 The issue is that some streets that are not one way in OSM data, are
rendered as one way by Craigslist.
 
 If you go to this ad and zoom in on the map you will see the arrows
designating one way streets, for example on Cliffrose Way
(https://www.openstreetmap.org/way/170048276):
 https://fortcollins.craigslist.org/gms/4991940913.html
 Here is the approximate area on the default OSM map:
 
 https://www.openstreetmap.org/#map=17/40.51930/-104.85951
 
 
 I looked at the data and all of the streets in question seem to be tagged
oneway=no. Admittedly this tag is rather superfluous in these cases - or
at least I believe it is, I am not the one that added it, but it shouldn't
be interpreted as indicating a one way street.

Does Craigslist also get oneway=-1 (traffic opposite to the direction of the
way) wrong?

--
Andrew


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


Re: [OSM-talk] Craigslist OpenStreetMap Rendering Issue

2015-05-31 Thread Lester Caine
On 31/05/15 12:24, Andrew Hain wrote:
 Does Craigslist also get oneway=-1 (traffic opposite to the direction of the
 way) wrong?

And oneway:cycle=no and the like ...

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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


Re: [OSM-talk] Craigslist OpenStreetMap Rendering Issue

2015-05-30 Thread Warin

On 31/05/2015 10:51 AM, Mike Thompson wrote:
I have posted this issue to the Craigslist feedback forum, but I also 
thought I would post it here to see if anyone has a specific contact 
at Cragislist that handles their map rendering.  They use - and credit 
- OpenStreetMap (which is wonderful), but I believe they perform their 
own custom rendering, which seems to be the source of this issue.


The issue is that some streets that are not one way in OSM data, are 
rendered as one way by Craigslist.


If you go to this ad and zoom in on the map you will see the arrows 
designating one way streets, for example on Cliffrose Way 
(https://www.openstreetmap.org/way/170048276):

https://fortcollins.craigslist.org/gms/4991940913.html

Here is the approximate area on the default OSM map:
https://www.openstreetmap.org/#map=17/40.51930/-104.85951

I looked at the data and all of the streets in question seem to be 
tagged oneway=no. Admittedly this tag is rather superfluous in these 
cases - or at least I believe it is, I am not the one that added it, 
but it shouldn't be interpreted as indicating a one way street.


I could remove this tag, but I feel this would be tagging for the 
renderer (actually someone else's renderer), and there may be 
legitimate cases for using oneway=no on a way representing a street 
somewhere else.


Why care? I would imagine to the majority of the users make no 
distinction between OpenStreetMap and Craigslist's rendering of 
OpenStreetMap, if the map is wrong, to them that simply means that 
OpenStreetMap is wrong.





I'd remove it.
Redundant information - data base bloat. Like vehicle=yes on a motorway ...

Perhaps these could be candidates for a mechanical clean up?

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


Re: [OSM-talk] Craigslist OpenStreetMap Rendering Issue

2015-05-30 Thread Marc Gemis
I've seen this topic being discussed here or elsewhere in the past. I
thought that the consensus was that in some area's (a Spanish town I
believe), it was ok to leave the oneway=no. The reasoning was that most
streets in that town were oneway=yes, and the oneway=no was used to
indicate that this road was surveyed and and an exception to the oneway=yes.

so a world-wide mechanical edit should not be performed.

regards

m

On Sun, May 31, 2015 at 3:22 AM, Warin 61sundow...@gmail.com wrote:

 On 31/05/2015 10:51 AM, Mike Thompson wrote:

 I have posted this issue to the Craigslist feedback forum, but I also
 thought I would post it here to see if anyone has a specific contact at
 Cragislist that handles their map rendering.  They use - and credit -
 OpenStreetMap (which is wonderful), but I believe they perform their own
 custom rendering, which seems to be the source of this issue.

 The issue is that some streets that are not one way in OSM data, are
 rendered as one way by Craigslist.

 If you go to this ad and zoom in on the map you will see the arrows
 designating one way streets, for example on Cliffrose Way (
 https://www.openstreetmap.org/way/170048276):
 https://fortcollins.craigslist.org/gms/4991940913.html

 Here is the approximate area on the default OSM map:
 https://www.openstreetmap.org/#map=17/40.51930/-104.85951

 I looked at the data and all of the streets in question seem to be tagged
 oneway=no. Admittedly this tag is rather superfluous in these cases - or
 at least I believe it is, I am not the one that added it, but it shouldn't
 be interpreted as indicating a one way street.

 I could remove this tag, but I feel this would be tagging for the
 renderer (actually someone else's renderer), and there may be legitimate
 cases for using oneway=no on a way representing a street somewhere else.

 Why care? I would imagine to the majority of the users make no
 distinction between OpenStreetMap and Craigslist's rendering of
 OpenStreetMap, if the map is wrong, to them that simply means that
 OpenStreetMap is wrong.



 I'd remove it.
 Redundant information - data base bloat. Like vehicle=yes on a motorway ...

 Perhaps these could be candidates for a mechanical clean up?

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

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