Re: [OSM-talk] HDYC, login requirement and "privacy"
On Sunday 07 May 2017, Frederik Ramm wrote: > > It is a common issue in OSM (and elsewhere) for people to use the > status quo as a reason. "Admin boundaries are not visible on the > ground and they are mapped, THEREFORE I can also map everything else > that is not visible on the ground" - no! And you're doing it the > other way round, saying "your privacy goes down the drain if you do > anything online anyway, so why should we at OSM take steps to protect > it more". But we also should be careful not to apply the 'analogy sledgehammer' the other way round - just because restricting access to data can in some case reduce privacy issues it is not necessarily always the best way to deal with such a problem. Specifically that putting a login via OSM account in front of HDYC makes sense for this specific tool and some specific concerns regarding it (mainly the 'invitation to stalking' matter) should not lead anyone to consider this a useful standard measure for all privacy related concerns. Side note: Mailing lists are a very different matter for a variety of technical and social reasons. I would say that the idea of restricting mailing list archive access due to metadata based privacy concerns is fairly far fetched (in contrast to content related concerns about privacy or confidentiality - which make much more sense) considering the archives show almost nothing of the mail metadata except 'From' and 'Date' which can be freely chosen by the user. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] HDYC, login requirement and "privacy"
Hi, On 07.05.2017 22:54, Nicolás Alvarez wrote: > Yet I don't know of any such platform that has rules on how such > metadata can be used, and I don't see anyone here arguing that we need > rules on the use of mailing list archive metadata. One thing at a time. Pascal's request for identifying yourself as an OSM user is a tiny first step. Farther down that road there might be conditions for the release of user-related information (e.g. "you can get this info but you have to affirm that you won't abuse that"). Making mailing list archives accessible to mailing list members only is also something that Mailman offers out of the box and that we could one day switch on if we like. It is a common issue in OSM (and elsewhere) for people to use the status quo as a reason. "Admin boundaries are not visible on the ground and they are mapped, THEREFORE I can also map everything else that is not visible on the ground" - no! And you're doing it the other way round, saying "your privacy goes down the drain if you do anything online anyway, so why should we at OSM take steps to protect it more". Perhaps: because we can, and because it's a good thing? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] HDYC, login requirement and "privacy"
2017-05-05 6:59 GMT-03:00 Frederik Ramm : > Today, if you are looking for a job and you're being interviewed by a > potential employer, the potential employer could say: "I can see from > OpenStreetMap that you've been editing a lot during the day in your last > job. Did you not have any work to do?" - and the employer would not even > be "wrong". Harvesting the full history file for totally OSM unrelated > information like that is not against any of our rules; it might be > against the law in some countries but certainly not in others. If you > publicly complained about what happened to you, it is very likely that > there will be many people like in this thread who will say "duh, you > idiot why didn't you use a pseudonym, didn't you read what you signed up > for, lah lah lah". > > I would like to come to a point where, if this happened to you in a job > interview, you could afterwards point to an OSM policy and say: Clearly > this company has violated OSM rules, they must have created an account > under false pretenses to get at this data and they're using it for > purposes not sanctioned by OSM. That won't make you get the job, but it > would at least make clear that we stand with our contributors against > abuse of their data. This scenario is not specific to OSM map edits at all. They could also use mailing list archives to see you have been arguing about OSM tagging conventions during work hours. Or see that you have been editing Wikipedia. Every web forum, mailing list, social network, wiki, etc. that has usernames and timestamps would be "vulnerable" to that. Yet I don't know of any such platform that has rules on how such metadata can be used, and I don't see anyone here arguing that we need rules on the use of mailing list archive metadata. -- Nicolás ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] HDYC, login requirement and "privacy"
On 4 May 2017 22:33:47 IST, Frederik Ramm wrote: >It doesn't matter that anyone can sign up and then view that data; we >can at least make people promise to only use the data for project >internal use when they sign up. While I'm not looking forward to having to login to use various tools, I understand that it might be a step in the right direction for privacy-sensitive contributors. But seeing how low this new barrier is, I don't think that we should advertise it as a privacy-preserving feature, because it'll give a false sense of security to the very users we are trying to help. It's also annoying that it migh increase "contribution-less account bloat", but that's something we have to live with anyway. I'd be more interested in annonymising features like a "randomize changeset and gpx timestamps a bit" account setting and providing a best-effort "delete my account and as much data as you can" button. These are more invasive and complicated than "login to see usernames" but they would be much more useful. -- Vdp Sent from a phone. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Revisiting traffic control and traffic calming
2017-05-07 9:30 GMT+02:00 Paul Johnson : > On Sun, May 7, 2017 at 2:25 AM, Jo wrote: > >> What about a type=traffic_sign relation? >> >> Where traffic_sign could be stop, give_way, parking >> > > I was thinking the typical highway=* tags for highway=stop, > highway=traffic_signals and highway=give_way. > > >> In case of a stop sign, we could include the sign on a node, role 'sign'. >> The node of the intersection, maybe role 'to'. The way the vehicle is >> approaching from, maybe role 'from'. >> > > Yes, that's what I'm suggesting. > > >> In case of parking it would make very clear on which ways there is >> parking and we would have central place to keep track of the conditions >> like "opening_hours" and tariffs, or specific requirements like permits. >> > > Parking already has a very clear case of way tagging for this. > To map the effect on the road network, I agree. To relate the traffic signs to those ways, we don't. I don't know if we'll be able to map all traffic signs and include all these relations (and keep them up-to-date), but then I also wasn't sure we´d be able to put entire countries on the map like we did, only ust a few years ago. It would be good to have a well thought out plan, so we can start doing it consistently. Polyglot ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Revisiting traffic control and traffic calming
On Sun, May 7, 2017 at 2:25 AM, Jo wrote: > What about a type=traffic_sign relation? > > Where traffic_sign could be stop, give_way, parking > I was thinking the typical highway=* tags for highway=stop, highway=traffic_signals and highway=give_way. > In case of a stop sign, we could include the sign on a node, role 'sign'. > The node of the intersection, maybe role 'to'. The way the vehicle is > approaching from, maybe role 'from'. > Yes, that's what I'm suggesting. > In case of parking it would make very clear on which ways there is parking > and we would have central place to keep track of the conditions like > "opening_hours" and tariffs, or specific requirements like permits. > Parking already has a very clear case of way tagging for this. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Revisiting traffic control and traffic calming
What about a type=traffic_sign relation? Where traffic_sign could be stop, give_way, parking. We can put a traffic_sign tag on nodes, where they get the country_code:specific_national_code like BE:C1. Several traffic signs can have an effect on several ways and nodes of the road network, so we could group them in such relations. In case of a stop sign, we could include the sign on a node, role 'sign'. The node of the intersection, maybe role 'to'. The way the vehicle is approaching from, maybe role 'from'. In case of parking it would make very clear on which ways there is parking and we would have central place to keep track of the conditions like "opening_hours" and tariffs, or specific requirements like permits. Polyglot 2017-05-07 8:57 GMT+02:00 Paul Johnson : > I think it's time that we seriously reconsider how stop signs, yield signs > and traffic calming devices are handled in all but the most simple (all > approaches to the affected node apply) cases. This largely after having a > protracted discussion with one person about nodes lacking direction and > this being a big factor in turn restrictions and enforcement being handled > by relations already (and really, the entire reason relations were > introduced in the first place). > > I'm thinking it's time to start mapping this similar to how we handle > enforcement and turn restrictions, ie, with relations, for all but the > simplest of cases, especially since the whole forward/backward direction=* > thing is nonapplicable to nodes by design. > > ___ > 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] Revisiting traffic control and traffic calming
On Sun, May 7, 2017 at 2:12 AM, Nicolás Alvarez wrote: > > Do you know of a case where you would have a traffic calming device > only affecting one direction, but not already have a reason to map > each road direction as a separate way? > Somewhat commonly. Oklahoma and Texas have a strong tendency to set down at least three sets of rumble strips on approach to a traffic light, stop, give_way or the side way of a T intersection when the speed limit is 55 or faster. Oklahoma Turnpike Authority also uses rumble strips to warn of the toll plaza on the state's only undivided turnpike. > I agree about the signs though. Relations add complexity, but I don't > see how else to handle that kind of directional signs... > This is a problem that can be solved via editors. id and JOSM both have excellent editors for turn restrictions that could likely be readily extended to handle enforcement, traffic calming, stop, yield and nonstandard traffic signal cases (and clean up traffic signal situations on SPUI interchanges, dual carriageways and other "messy" traffic light situations that get mapped as multiple ways intersecting but are handled by a single assembly of traffic lights or an interlocking pair of traffic lights as functionally a single intersection). ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Revisiting traffic control and traffic calming
2017-05-07 3:57 GMT-03:00 Paul Johnson : > I think it's time that we seriously reconsider how stop signs, yield signs > and traffic calming devices are handled in all but the most simple (all > approaches to the affected node apply) cases. This largely after having a > protracted discussion with one person about nodes lacking direction and this > being a big factor in turn restrictions and enforcement being handled by > relations already (and really, the entire reason relations were introduced > in the first place). > > I'm thinking it's time to start mapping this similar to how we handle > enforcement and turn restrictions, ie, with relations, for all but the > simplest of cases, especially since the whole forward/backward direction=* > thing is nonapplicable to nodes by design. Do you know of a case where you would have a traffic calming device only affecting one direction, but not already have a reason to map each road direction as a separate way? I agree about the signs though. Relations add complexity, but I don't see how else to handle that kind of directional signs... -- Nicolás ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Revisiting traffic control and traffic calming
I think it's time that we seriously reconsider how stop signs, yield signs and traffic calming devices are handled in all but the most simple (all approaches to the affected node apply) cases. This largely after having a protracted discussion with one person about nodes lacking direction and this being a big factor in turn restrictions and enforcement being handled by relations already (and really, the entire reason relations were introduced in the first place). I'm thinking it's time to start mapping this similar to how we handle enforcement and turn restrictions, ie, with relations, for all but the simplest of cases, especially since the whole forward/backward direction=* thing is nonapplicable to nodes by design. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
