Re: [OSM-talk] Intercultural differences / cultural diversity / OSM communication behaviors
It seems the big joy in all this is that we are all quite correct. It isn't so much a conflict as it is "what comes next." Sure, there are good questions that haven't been answered yet, I look forward to those. OSM isn't a battle. It is a project. We grow. Does it matter what the survey might tell the team, does it matter what the realpolitik or composition (its intentions might be...) of the team might be? It has formed, Courtney is part of it. We ARE having this conversation. It's gonna be long, I can tell, part of a dialog we've been having all along, really. Some topics are out in the open more. Uphill climb, to be sure, though lots of us are pedaling. Oh, and like the song says, "we're an adult now." OSM has toys to share, toys to craft, toys yet to build and more. We do keep learning to share our toys: it only makes us stronger. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Intercultural differences / cultural diversity / OSM communication behaviors
On May 3, 2023, at 11:07 AM, John Whelan wrote: > A very accurate summation in my opinion. > Imre Samu wrote on 5/3/2023 1:03 PM: >> Courtney ezt írta (időpont: 2023. ápr. 30., >> V, 19:06): >> This conversation has opened up important new questions. Why is the main >> "Talk" channel the only one that is producing pushback? Why is it the only >> one that is producing such a negative tone? >> >> Hi Courtney, I agree this is an excellent summation and an important takeaway from it that our Etiquette Guidelines may need bolstering in these directions. In fact, I quoted Imre's short essay on our community forum [1] in a discussion about trail_visibility that I slightly hijacked off-topic (and have since steered back on-topic) about European / German-speaking usage of the word "wasteland" (which my US-English ear finds somewhat harsh) versus my preferred word for these areas, which I and others might consider "wilderness." OSM is a global project (somewhat obviously, but apparently often forgotten or ignored). We do well to strive to understand, embrace and even celebrate cultural and language differences as part of our greatest strengths. Köszönök mindent, Imre. [1] https://community.osm.org/t/tag-trail-visibility-proposed-improvements-for-this-descriptive-tag/97865/98 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Talk-GB Digest, Vol 197, Issue 27
I don't totally disagree with Greg's characterization of "unreasonable," as
"standardized / hashtagged" changeset comments are curt (even a touch rude) if
they are not super-well-documented (widely vetted, spoken about...) as to
what's going on, and easily have the ability to hide errors or even be
potentially harmful (whether intentional or not). At the same time, John hints
that entities like a National Trust can be bureaucratic and move in those kinds
of ways. Well, yes.
OSM ("Open" being our first name) has a tradition of being transparent. I do
like the movement away from "standardized" changeset comments to those which
are "more representative." Yes, +1 there. Do better, as well as is possible
here. Really, on all aspects of participating in OSM: be proud of your
contributions here, National Trust (Olivia). OSM can be used as a bit of a
"chalkboard" (or watercolor easel or wall to be spray-painted...) when we build
things and they are under construction. Though, let's be talking to each other
and agreeing that we're using tags we understand to mean what they say and say
what they mean. It is not OSM asking a lot as we ask this, it is asking "the
right amount."
Get a path (way) or POI (node) "in" the map, first, minimally tagged (even just
highway=path or add access=no until this is figured out). Accurate,
higher-precision location is important, use (e.g. GPS) equipment to the best of
its abilities (maybe you use a 16-channel satellite receiver unit with high
trees / dense forest, for example). You can refine / enrich data in subsequent
iterations, adding access, route, safety, fee-related, resources / amenities
(water, restrooms), whatever you like later. Get "the bones" into the map
first. The muscles and skin and hairstyles happen over time.
Entities like a National Trust can use OSM for their purposes, appearing to
have a toolchain (of rangers and volunteer mappers and a comm path of
repetition and refinement there) which are on a longer-term. That's OK, in
fact it gives plenty of opportunity to explain, document, engage in dialog, et
cetera. We're here. As long as things go "good, better, best" (within a
reasonable timeframe), it's good. As the data are vetted as good, they'll get
better, that's simply how it works. (Openly, transparently). You (2nd person
plural, including Olivia) know what to do; this is small stuff. Talk to one
another, be open and better about being open...lather, rinse, repeat. I think
we're fine here.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] replace some obviously mistaken surface values by their clear intended meaning
On Feb 11, 2023, at 9:41 AM, Mateusz Konieczny via talk wrote: > I propose to replace following surface tags by doing an automated edit: > ... To ma dla mnie sens, Mateusz. (Makes sense to me). ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] Adoption of OSM geometry as state mapping base
My local chapter of OSM is in the USA (OSM-US), but yes, I think you (all) are on the right approach here: the "Australia / Oceania Chapter" (I think it is, or is called) as a semi-formal sub-community within OSM, or even an "official" chapter, is the "first stop" along the way of this sort of "thread the legal needle" here, then it might go to the Foundation (LWG, Legal Working Group, I believe) as a "they'll figure it out" last stop, perhaps. So, now at the regional level, maybe at the "global, legal" level (the Foundation's LWG) if not fully "resolved" at the regional / Oceania level. Sorry to be a bit hazy, but it should come into better focus soon; somewhere around there, it WILL get resolved. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Should we be mapping transformers and powerlines?
On Jan 18, 2023, at 7:13 PM, john whelan wrote: > Perhaps you could expand on the benefits of mapping them? I don't wish to sound antagonistic, but that's like asking "what good is our map" and expecting the infinite "creative and unexpected purposes" that have, do and will evolve from our data to be a complete answer. It can't ever be complete. Power lines "exist." They are "in the real world." Sometimes they are "in the way." (Perhaps I am flying my drone or hang-gliding). Their poles and towers sometimes have wide swaths upon the landscape and make a human, technological path wherever they are, they deserved to be mapped. So do their often-fenced substation structures and related infrastructure. If an owner / power company needs to beef up its security, that is little to no concern of mine as an OSM mapper. It's a valuable conversation to have, I'll agree. I don't like hearing about rifle-accurate attacks that take out quite expensive infrastructure with a box of well-placed bullets, but that is the world we live in (in some places). The world we map in? I'll keep on mapping (including power infrastructure, if for no other reason than "others make pretty spider-webby renderings" of power infrastructure, and I like to look at those). I'm not a nutter with a gun, I'm a mapper. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Should we be mapping transformers and powerlines?
I'd like to say "oh, please..." because this seems a bit harsh. But I understand that people can be sensitive. But this is OSM and I'd like to believe we live in a world that is more free rather than less free. What's next, do we stop mapping pre-school or kindergartens because they have children? Criminals are going to use maps, yes, that is going to happen. We mappers ourselves are not criminals for mapping. Map. Map well. Criminals will be criminals. While there are book banning people, librarians are not criminals. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'
I am “with” Andy here, yet I am also “with" Frederik here: you might be able to get away with this “most of the time,” but when it fails (and it will), you’ll be disappointed and perhaps even upset with OSM. There is simply no reason why we should be suggesting or supporting this. Because it WILL fail. For that reason, I say “don’t do it.” And please don’t suggest others should, either. At least once, it won’t end well, and that will be one too many times. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'
I'll state even more strongly than Frederik just did: "linking to an OSM
object by ID and expecting the ID to remain constant is asking for trouble" is
putting it mildly. It IS trouble. All it takes is one single change to one
single datum and boom, the assumption that doing so can work is proven false.
I'll offer to be the first to change an ID to do this just on the general
principle that it proves this is a bad idea.
So, this (linking to an OSM object by ID and expecting the ID to remain
constant) is a non-starter. Right here, right now.
On Jan 2, 2023, at 10:11 AM, Frederik Ramm wrote:
> Hi,
>
> On 1/2/23 18:57, Sören Reinecke wrote:
>> As OpenStreetMap is playing an important part in the geospatial world, the
>> OSMF should try to get IETF convinced.
>
> Until now we've concentrated on making a good map, rather than convincing
> others that our map is good ;)
>
> I think that linking to OSM objects by ID is only relevant in the immediate
> and time-limited QA or debugging context ("does anyone else think way 1234
> has a problem here") because our IDs are not stable; linking to an OSM object
> by ID and expecting the ID to remain constant is asking for trouble.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] razed railways and other things that don't exist today
Thank you, Warin, thank you Mike, thank you Zeke: With Warin's "clarifications," I think we move closer to something approaching a reasonable way to say this. I would correct "renders" to "renderers," and perhaps change it to "OSM's database and renderers...", but aside from that, +1. > On Dec 11, 2022, at 12:17 AM, Warin <61sundow...@gmail.com> wrote: > > > On 6/12/22 06:39, Mike Thompson wrote: >> >> >> On Mon, Dec 5, 2022 at 11:22 AM Minh Nguyen via talk >> wrote: >> Vào lúc 09:55 2022-12-05, Zeke Farwell đã viết: >> > That is a good summary, though "Once the OSM available satellite imagery >> > does not show the feature" 1) There are other sources that an armchair >> > mapper can use other than imagery, such as the Strava Global Heatmap, the >> > USGS 3 DEP data (in the US), and GPX data that has been uploaded to the >> > OSM server. >> 2) The term "satellite imagery" also excludes street level imagery, such as >> Mapillary >> 3) Technically some of the imagery we refer to as "satellite" is really >> "aerial." >> >> "Once the feature truly no longer exists and is no longer evident in any of >> the available remote sources commonly used to edit OSM, including overhead >> imagery (satellite/aerial/drone), street level imagery (e.g. Mapillary), GPS >> traces/heatmaps (e.g. Strava), and elevation data (e.g. USGS 3DEP) the >> feature can be deleted" >> >> > > I have abbreviated the above to be; > "The following tags function is to reduce the possibility of a mapper > remapping the feature from existing available sources used to edit OSM, e.g. > satellite or aerial imagery, that shows the old state of the feature. Once > the OSM available sources do not show the feature, the feature can safely be > removed from OSM. Renders cannot rely on OSM preserving physically vanished > history. " > > I don't want to use too many words .. so as not to obscure the basic > intention. Listing all the possible sources is not necessary... ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] QA tool for finding nameless highways that are armchair-fixable
On Nov 28, 2022, at 5:57 AM, Maarten Deen wrote: > Your remark seems reasonable ;) Thanks, Maarten, I’m chuckling with mirthful laughter here. > Thing is: this is not meant as a bot, so the usual caveats apply. That IS an important consideration; thanks for highlighting that aspect. I didn’t know there were / are “usual caveats,” and if there are some, they should be widely known, especially by people who discuss these things in a place, manner and time such as “this, here and now." > It just serves as a highlight of "something might be wrong here", like so > many QA tools do. What the user wielding the QA tool does with that is his > choice. > Does he automatically correct it? Wrong for OSM standards, but who is going > to stop him. Just like who is stopping anyone using a QA tool and > armchairmapping something that he really can not see from a distance. I’m aware of this distinction and again, it is important. Among others (OSMCha [1], there are any number of such tools...), I use Geofabrik's excellent OSM Inspector [2], which “merely shows,” (and superbly) rather than “and fixes, too." Perhaps another example will help: JOSM’s Validator tool gives the opportunity (between clicking the Upload button and actual data being uploaded to OSM) to review “flagged” problems, some as mild Warnings which could be ignored (but shouldn’t be), some as more serious Errors which really ought to be solved. For some of these problems, JOSM is clever enough to “light up” (activate in its user interface) a “Fix” button which is smart enough to “take the right OSM actions” to actually fix the problem. This is great when available, as it solves the tedium of manually doing something which can be automated (so, click the Fix button). And, as JOSM (and OSM) develop, while more and more identified problems are automatically-solvable, some certainly are not, and so the Fix button remains dimmed, meaning “these must be fixed manually.” That’s the distinction I’m making here: I haven’t analyzed Lukas’ code to see where / when / whether (and how) he does this (and again, there are certainly cases where this MIGHT be possible, and where it is, great, do so). I am simply saying “there are times and places where an automated tool CAN fix things” (like naming nameless highways…though this really IS tricky, speaking from personal experience), and there are absolutely times and places where it can’t. Both tool developers (especially) and also, those who wield such tools must be aware of this “sometimes we can, sometimes we can’t” distinctions. And I’m not saying Lukas has done this, but in this realm (and because I know a couple things about “quality” and “mapping” I can say this): it is all-to-easy to glibly make assumptions which are better left not made. Especially in the context of OSM, wider vetting (exactly what Lukas is asking for here) is exactly what is needed. Though, as we get wider input that includes “seems reasonable,” I urge caution. I’ll stop here, as I don’t want to repeat myself. [1] https:osmcha.org [2] https://tools.geofabrik.de ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] QA tool for finding nameless highways that are armchair-fixable
See, saying “seems reasonable” actually seems reasonable, until one realizes one doesn’t truly know. Ask yourself if others in OSM would agree if “seems reasonable” is good enough to meet OSM’s criteria for data entry: you’ll get mixed answers, though a sizable number will say “not really good enough.” You might even have a very high degree of confidence…though, ask yourself if you want to navigate (or otherwise rely upon) a map with what amounts to guesswork. That’s how the camel’s nose (of creeping errors, one datum at a time) gets into the tent (map). I mean no disrespect to camels. I have decades of experience in software quality assurance at top companies (Apple, Adobe…), so I have great respect for Lukas’ tool finding / identifying errors (emphasis on those verbs), it’s what is done after that which matters. Guesswork? Mmm, no, I’d prefer not. Our usual “on the ground verify” (or otherwise equivalent, like “I already know that”) criteria: yes, much better. We’re not quibbling (slightly objecting to trivial matters) here: these are fundamental decisions each and every mapper makes as they enter data into our map database. I strive to keep that quality as high as I possibly can, though everything I say here is simply one person’t opinion. Let’s be careful with power tools: they’re great at finding / identifying errors, whether they can “fix” the data after that must be carefully considered case-by-case. On Nov 28, 2022, at 12:44 AM, Marc_marc wrote: > Le 28.11.22 à 00:43, Dave F via talk a écrit : >> a "high confidence" interpolation, from an armchair or anywhere, will lead >> to inaccurate data being added to the OSM database. > > if you have a road in 3 segments A B C and A+C have the ssame name, > then not only does it seem reasonable to me to add the name on B > but also the reply "do a survey" is a dogmatic answer: the ground > does not contain a sign every time osm cuts a way because of a change > in the number of strips for example. > So by survey, you will be reduced to deducing that a segment between > 2 others with the same name, probably also has the same name ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rent-a-crowd needed JOSM Microsoft store
Yes, thanks much, James! (For linking "Reporting Infringement to Microsoft"). I do wonder if simply forking and charging money for existing open-source software is an egregious slap in the face to OSM (JOSM developers, especially), although I'm not an attorney. So, I'd urge our LWG / legal-beagles to take a look at this, please. On the other hand, if there is something "value-added" to the fork that justifies charging money, maybe it's OK. > On Nov 27, 2022, at 8:26 PM, James wrote: > > https://www.microsoft.com/en-us/legal/intellectualproperty/infringement > > On Sun, Nov 27, 2022, 11:15 PM john whelan wrote: > You can only leave a review if you download the software. > > Both are JOSM, one is a fork which costs money which goes to the person who > created the fork the other is normal JOSM which is free. > > Cheerio John > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] QA tool for finding nameless highways that are armchair-fixable
Without wishing to "diss" (disparage) Lukas's tool (I haven't evaluated it), I would also urge caution here, for exactly the reasons DaveF outlines. I'm also a partly-armchair mapper, but not (usually, if ever) using Python tools, rather knowing that my "armchair-ing" is going to be of high quality because I well-understand (and have many years of practice) with OSM's tenets of "on the ground verifiability" and such. I'm also a "real world" mapper (where I "get out into the real world" and use a GPS and a notepad/pencil...), which I believe should be a prerequisite for being an armchair mapper: that's how you learn and get good at knowing how to armchair-map with high quality and without guesswork that can (and usually does) lead to errors being entered. Especially with going from "no name" to setting a name=* tag to "something" (authoritative), this can be a very ticklish undertaking, I've experienced the difficulty in doing this first-hand, and I usually "duck out" (end the endeavor) as "too likely to introduce specious errors into our map data." High quality armchair mapping (which does not introduce errors) is not easy: it takes practice, knowing what you are doing, likely some deeper knowledge of the geographic area, "how things are done (and/or mapped) around there" and probably something like "I know quite well how to map bike routes (train routes, landuse, forest boundaries..., or whatever you might be mapping)." If you meet all of those "high bar" quality standards, AND you understand what Lukas' Python / pyosmium software does / will do, you might want to check it out and see if it can be a "power tool" for your armchair mapping. I've set high-quality standards for myself (really, I wouldn't map in OSM if I did not), perhaps you should, too. And then, and only then, maybe use power tools to help you, going slow at first, with caution and evaluating your own feedback from the map. I'll be curious to hear feedback from this, too. Thanks for your efforts, Lukas: I genuinely hope they help our map! > On Nov 27, 2022, at 3:43 PM, Dave F via talk wrote: > > Most roads don't have names. > > Any comparison has to be done against an authoritative database or on ground > surveying, for the area in which you're searching. > > "where the name can be interpolated from neighbouring ways. This allows to > detect and armchair-fix a (small) subset of these cases with high confidence. > " > > I have a "high confidence" interpolation, from an armchair or anywhere, will > lead to inaccurate data being added to the OSM database. > > Cheers > DaveF > > > On 27/11/2022 20:16, Lukas Toggenburger via talk wrote: >> Hi all >> >> As you might know, OSM data contains a lot of highway=* without name=*. >> Check your region using the following query: >> >> https://overpass-turbo.eu/?Q=way%0A%20%20%5Bhighway%5D%5B!name%5D%0A%20%20(%7B%7Bbbox%7D%7D)%3B%0Aout%20body%3B%0A%3E%3B%0Aout%20skel%20qt%3B >> >> I wrote a Python tool (using Sarah Hoffmann's pyosmium) at >> https://gitlab.com/ltog/ohni that is able to detect such highways in a >> planet (extract) file and report the ones, where the name can be >> interpolated from neighbouring ways. This allows to detect and armchair-fix >> a (small) subset of these cases with high confidence. The tool is tailored >> to minimize false-positives. >> >> Please check it out and give feedback. >> >> Best regards >> >> Lukas >> >> ___ >> talk mailing list >> talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk > > > ___ > 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] Rent-a-crowd needed JOSM Microsoft store
If choosing which version is "legitimate" (or preferred) is important, and "leaving a review" is a (one) method for communicating that, I would underscore that if you do leave a review, make very clear how one differs from the other. On Nov 27, 2022, at 5:33 PM, john whelan wrote: > > Agreed but some do and currently both have one review each so it isn't that > clear which is the official OpenStreetMap editor. > > Even a couple more reviews would help. > > Thanks > > Cheerio John ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] razed railways and other things that don't exist today
Some historical perspective on a project like OSM, its growth, the social aspects of "what that means and does to tagging" over time might be helpful. The dates and numbers I'm about to offer as examples are wholly illustrative (and indicate not arithmetic, but geometric growth, a very powerful force) and are no way based in reality because I've "done the research on the actual numbers," because I haven't. I'm simply making a point or two. Let's say early in OSM's history, oh, 2005 or so, there were 10 mappers worldwide who began the first tendrils of rail mapping, and that by 2006 that grew to 50. People in sizes like that can talk to each other and agree on things to a 100% level of agreement, or pretty close to 100%. This is because the "problem set" has a small enough size that its "solution set" can be hashed out in a few emails, not many kilobytes of wiki, and heads nod in almost perfect unison among a relatively small group of people. If you are "in the club," it's easy, and even quite fun! By 2007 (and, for example, the USA's TIGER Import of hundreds of thousands of km of rail) there are 500 active, enthusiastic rail mappers in OSM, and lots of work to do, and it feels like maybe "1% of the problem" (of mapping all of Earth's rail accurately) has barely had its surface scratched. On the social dimension, this remains manageable, especially as things fragment in to different countries, and hundreds of people still might only be a couple, a few, or maybe at most a dozen, even in a very complex rail area (like Germany or greater Europe): "localization of the solution space" really does help a lot. This remains doable, but people eye the future and imagine public transport and better renderers, and so allow a timeline of a few years for these things to develop. It remains relatively easy, especially if you "remain local / regional," and "others (clever ones, busy ones, more-curious ones...) "think globally." OSM is fine. Fast forward to 2010-11 and now there are many thousands of rail mappers and things like PTv2 move from "good ideas" to "coming on strong," OpenRailwayMap gets rolling, major differences in how rail all over the world show that the problem is large, maybe quite difficult if people are honest, and yet it remains manageable as the tools get better and the numbers, while growing and at least medium-sized, are not totally overwhelming. I can go on with real life examples (from this time period of 2014-16-18-20-22, and personally, as I've given SOTM talks, one on rail...) and had a fair bit to do and say about "rail growth in OSM" in my own country (USA), I've seen this growth — geometric growth — and how it has had to cope with rail over the one-to-two centuries this transport technology has been around (including ORM and OHM as examples of how OSM "maps" it, both logically and literally). There are now hundreds of thousands of rail mappers in OSM, in over a hundred countries. Think of the "social dimensions" of not only "that" but "how that has grown and continues to grow." The amount of fragmentation of understanding (especially given humans' many languages and both the limitations of using English and the "Balkanization" of isolated language communities) has now become quite large...maybe "huge" by some people's estimation. Logically mapping how we have, do and will put "razed" (demolished...all the other flavors) of "doesn't (completely) exist today" rail into tagging schemes that we all agree upon, especially given that many don't have OSM's now-decades-long historical perspective of "how things (like tagging) have grown up w.r.t. rail in our project" are now "difficult," but remain explainable and doable. I believe we are up to the task, but it is complex, the geometric growth compounds this, so do the relatively long (in software-, data-project world sense) timescales, and especially (in a project like OSM), the social dimensions (of consensus, multilingualism and so on). We (all of us in OSM who might map rail and other things "that don't exist today") are still "in the club," but it is less easy to talk amongst ourselves about why we "do this" (but "not that"). And, I'm simply talking about "razed railways" (and a bit more). It's big and complex, and doesn't "shoehorn" (get forcefully or uncomfortably crammed) very well into a small box. Now, please understand there are many, many other topics in OSM which are not completely unlike "razed railways" (and why they are an "odd duck" and don't seem to categorize well, or need a lot of explaining, or both). One of my points? Often, the history of how we got here and oddities of why go a long way to explain. But the natural human desire to understand quickly and not necessarily digest all of that makes for quizzical or difficult understandings. Thank you for reading. ___ talk mailing list talk@openstreetmap.o
Re: [OSM-talk] razed railways and other things that don't exist today
As usual (nearly all of the time!), I appreciate and agree with your well-stated clarifications, Frederik! ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] razed railways and other things that don't exist today
On Oct 25, 2022, at 12:42 AM, Warin <61sundow...@gmail.com> wrote: a > Question: about mapping of old railway infrastructure. Without "meaning to be mean," I say "oh, no, not again!" I say it like that because OSM has had this discussion many, many times. I'll be relatively brief here and have at it with a short version, one more time. OSM maps old railway infrastructure because it has very long-lasting effects on the land, affecting landuse, transportation patterns and more for decades, sometimes for centuries. OSM (and OHM, OpenHistoricalMap, considered by some a "sibling project" of OSM) map(s) these, and OSM documents [1] (even with several pictures) that we do, saying "mapping such features is acceptable where some (of the infrastructure) remains." Yes, there remains some controversy, the wiki goes to some length to explain what this is, what is a borderline case, etc. But this is a topic which has been thoroughly discussed, even as it remains being discussed to this day. Regarding other things which "don't exist today" which are NOT railways, well, those are a separate topic (from railways). There: "I didn't fix it..." but I hope that helps. [1] https://wiki.osm.org/wiki/Demolished_Railway#What_is_sufficient_to_map_a_former_railway ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] I’m running for OSMF board and I’ve set up office hours for questions
On Dec 3, 2020, at 6:12 PM, Michal Migurski wrote: > For those using or defending rape metaphors, shame on you. I take offense (and will not be shamed) at Mike's gross mischaracterization (after I took GREAT pains to be painstaking) of my reiteration of Frederik's analogy of offensive-to-women behavior by a politician being something we should be highly wary and suspect of in our board election. NEVER was the word "rape" used, the highly offensive behavior was called out AS highly offensive for the purpose of making an analogy: "don't be sweet-talked by people who act highly offensively while promising not to act highly offensively after they are elected." Moreover, such highly offensive behavior (certainly not rape) was NEVER condoned by neither Frederik nor myself. Wow! Frederik has no reason to be (a)shamed, he simply used strong language to say "be careful of false promises by deceptive people running for high office — you shouldn't be surprised when they remain deceptive after being elected." (Some may he say did so with a colorful, perhaps offensive example – but I am certain him offering an example of heinous behavior does not mean he "defends rape.") Wow! And, certainly I have no reason to be (a)shamed for doing my utmost to clarify that, while pointing out that such behavior of blaming the one who calls out such behavior (as, Mike, you seem to be doing to Frederik here, once again) is often exactly the same sort of abusive behavior! If we get this sort of misunderstanding from Mike mischaracterizing what happened HERE, well, I leave to this list to imagine what he might do if elected. Mike, your behavior and words — as do mine, as do Frederik's — are here on display for anybody to reach their own conclusions. Yes, you have a lot of work in OSM to your credit, but you certainly made a mess of this. You might say Frederik "baited" you (I disagree), but it is the mark of a true leader who can understand someone making an analogy versus twisting it (repeatedly!) into something that it isn't, "blaming he who calls out bad behavior." Especially when you denigrate him with something he didn't say. Some might say this is a misunderstanding, though in light of what I wrote earlier about blame-shifting, please understand this behavior is often deeply entrenched, often not being seen for what it is in the eye of the beholder. I would love for this list to get back to topics which are much more cool (literally and figuratively), as once again, I type my words here to generate light, not heat. While I give Mike one (single) point in his favor for recently replying and (at first, generally) sticking to topics, the one-line "zinger" he ends with that I quote above rather rudely wipes all the nice pieces off the board, subtracting far, far more than his one, single point. So, really, shame on you, Mike. Please, let's keep it civil and honest here. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] I’m running for OSMF board and I’ve set up office hours for questions
Mikel: I’m disappointed to see you characterize Frederik’s characterization of behavior as “garbage;” to do so is a red herring (intentional distraction). While I don’t want to put words in Frederik's mouth (indeed, I said I fully understand why he used such colorful language — to vividly identify what he sees as actual or perceived disingenuous or deceitful behavior), Frederik did so to identify hypocrisy and aggressive abuse. This is because identifying and calling out abuse is the first step is tamping it down when it (or even its potential) is seen in any group — whether a family or a foundation. A sad but true fact about people who abuse is they frequently “project,” blame-shifting and deflecting their own atrocious behavior (abuse of women, abuse of power, aggressive power plays…) onto the very person who is victimized or who calls out and identifies this behavior. This (bullying) can be a devastatingly effective tactic that actually re-victimizes the target of the abuse, making him or her appear to be the crazy (weak, abusive…) one in these actively aggressive acts. It also intimidates “good (people) who say nothing and do nothing about those who perpetrate bad or evil acts” (I paraphrase) into CONTINUING to do nothing. This allows the perpetrator to continue to get away with the abuse, effectively silencing many who would defend not only the single victim (target, survivor…) but those in the greater group (family, congregation, company, foundation, organization, country). The entire point of using such strong and colorful language is not to “make a point with garbage, further promulgating garbage.” It is to highlight abuse as abuse — raw, difficult and uncomfortable as those facts are. Pointing out that somebody else engages in atrocious behavior (and using strong language to do so) does not make the one pointing that finger a “slinger of garbage.” This is an old (yet sadly, quite effective) trick from the playbook of nasty, aggressive people, especially as they put on a public face of charming “nice guy.” This often results in one who identifies dangerous perpetrators of aggression, simply in their quest to call it out, becoming suspect themselves: “look at the histrionic, crazy drama-queen behavior by this unfortunate, name-caller” (but he won’t say “victim,” as that would identify the psychosocial dynamics of what is truly going on). This ruse has existed forever in the history of people who exercise power with terrible acts of aggression while remaining covert as they do so, pointing to others as “garbage slinging, accusatory, overly dramatic / histrionic, name-calling, unstable people.” It’s a sad, old trick, and the only way to stop it is to identify it and have it recognized by “good people who do (or say) SOMEthing” about it, rather than perpetrating the evil themselves with their silence. In many years of often close and intimate interaction / collaboration with Frederik in OSM, I have never, not one single time, even had a HINT that he “evokes violence against women.” That is a highly inflammatory statement, especially as you offer no evidence of it in what appears to be blame-shifting, when all Frederik did (it appears to me) was to make an analogy of one leader’s atrocious behavior having the potential for similar bad havior to infect our Board. We should call that out as we see it, and that is what is going on here, nothing more. Blame-shifting in the face of identifying bad behavior is something I (and others who have experienced this first-hand for what it is) find this behavior of yours highly suspect. I apologize to the list for going into the deeper and darker aspects of human behavior here. Sometimes, it is required to do so. SteveA On Dec 3, 2020, at 3:32 AM, Mikel Maron wrote: > Thanks Mateusz, I agree. Points can easily be made without such garbage. > Unfortunately Frederik has a habit of using rhetoric that evokes violence > against women. I’m not saying that he or anyone here personally holds biased > views about women. But the effect is the same, it degrades our entire > community. And we wonder why there are no women running for the board. > > Mikel ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] I’m running for OSMF board and I’ve set up office hours for questions
While I have travelled widely, I call California home (and have for several decades) so I unapologetically have a parochial perspective from the USA. Clifford, I deeply respect you, Frederik and many others in OSM: it is a global project about all of Earth (and its humanity, among other things). I agree with you about being exhausted at relentlessly hearing a shadowy US president repeatedly lie and bluster his way through the most embarrassing period of “leadership" in our country’s history. We (indeed, all of humanity) will eventually heal from these wounds. However, sometimes, as when we have abusive, naked aggression inside of (sometimes at the very top of!) institutions, we must call out such atrocious behavior. We call it out to say “we will not stand for this.” Sometimes, colorful language is used to draw attention to this. Sometimes, because people either are not fully aware of this in their experience, wish to turn away from looking at evil, or because they are part of those who "say nothing about bad men” (in the sense of John Stuart Mill’s quote, while "good men...look on and do nothing") the very nature of nasty, disingenuous people who mislead, lie, deceive, do not recuse, demand unwarranted loyalty, refuse to play by the rules, “stack the (court, Board)," slander… must be so vividly brought to light that strong and colorful language IS required. I understand why Frederik used strong language. It is (usually) not pleasant to countenance what either is or looks like underhandedness, attempts to mislead or disingenuous behavior. Yet among friends, families, groups, institutions, companies, societies, facing any ugliness which might rise from within is a necessary chore. Figuratively put a clothespin on your noise at the whiff of stink if you must, but let us not censor as “completely inappropriate” what are topics of critical importance to the present and future of OSM as we discuss the supremely important topic(s) of conflict of interest (among others). These are “front burner” issues and we must not shy away from candid discussion about them. If strong and colorful language must be used (and indeed, sometimes it must), let us remain respectful, not make personal attacks and offer our very best to keep (national, parochial, partisan…) politics out of it, remaining as objective as possible. These are difficult times. Let us retain good senses of our humanity, lest we devolve from even being human. OSM has what it takes to make good decisions. Every day, today included, we put that to the test. SteveA > On Dec 2, 2020, at 5:14 PM, Clifford Snow wrote: > > Frederik, > I've had it with four years of listening to Trump. Not only don't I want to > hear it on OSM but it's completely inappropriate for a mailing list. Can you > please respond in a constructive manner. > > Thanks, > Clifford > > On Wed, Dec 2, 2020 at 3:45 PM Frederik Ramm wrote: > Hi, > > On 12/2/20 23:09, Mateusz Konieczny via talk wrote: > > FB’s attribution to OSM is available to any viewer in a place that > > is commonly associated with attribution. > > > > Barely visible icon that must be clicked is not a standard place for > > attribution. > > Agree with Mateusz, and I'm just flabbergasted how someone can kick our > license in the groin and have the audacity to ask for the community to > thank them for it with a board seat, where they will be tasked with > upholding values they apparently don't share. > > If Mike Migurski at least had the decency to say: "Yeah, my employer > sucks with attribution, I know, and I'm trying to get it fixed." I > wouldn't believe him but at least he'd say something that is ok. But > instead he says "y'all suck with your baseless ideas of attribution, > please vote for me." > > Anyone who thinks that, once elected, Mike will put OSM's interests > before those of Facebook because that's his job as a board member, think > twice. People have thought the same about Donald Trump - yeah, this > whole grab-them-by-the-pussy talk is just showmanship and once elected > he'll be more presidential. But don't be fooled. Mike is going to grab > our licence by the pussy just as he promised he would, and he's being > paid a fine salary for that from one of the most disturbing mega-corps > on the planet. > > 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 > > > -- > @osm_washington > www.snowandsnow.us > OpenStreetMap: Maps with a human touch > ___ > 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] Examples of good paid mapping?
On Sep 11, 2020, at 1:06 PM, James wrote: > I've been paid in the past to do mapping for someone, but I was already an > active experienced osm mapper beforehand. > > How to be successful: > Listen to osm experts/community and not fight against them > Use existing tags on the wiki, don't invent your own > Verify data accuracy as much as you can, not dump data > > When merging data, verify if data is older than yours, locals usually have a > better sense of what buildings/pois have been demolished/exist. Great question, Michał! I've been paid by clients to both map in OSM (so the database is consistent with my client's expectations at the same time it is "correct" according to OSM community standards) and using OSM to make a map (a map product that was included in a published book, for example). I'm 100% in agreement with James: listening to the greater OSM community (along WITH your client's needs) is paramount, lest your edits get redacted. Use existing tags: reading wiki and sampling existing data with taginfo or Overpass Turbo queries can go a long distance at researching "what is" in OSM (perhaps rather than what you might "wish to be"). If what you do can be considered an import or entering new data (most paid gigs are exactly that, while some smaller set improve existing data), DO verify accuracy on existing data to the greatest extent practical, best to do so both before and after your work. Actively seek and implement high quality (top-level precision, thoughtful, careful, community-accepted accuracy in tagging, keeping any required / expected communication or status reporting frequently updated...) throughout the project. Small consultancies like mine that do "paid mapping" might not seem an obvious best source to ask this, but as our answers resonate with "excellent work, pays attention to quality..." we really do "lead by example," however minor our efforts may seem. Bigger companies and tech giants that use or intend to use OSM: please respect our community (and its standards and practices) first and foremost. You are welcome — though, everybody appreciates respect. As is true in many endeavors, it takes a long time and is challenging to build up a good reputation, which is easily harmed by foolish, anti-community blunders, so avoid these! Finally, when in doubt, seek consensus: plenty of community wants to help make a better map, but only with agreement does that happen. SteveA > On Fri., Sep. 11, 2020, 3:56 p.m. Michał Brzozowski, > wrote: > Hi all, > Do we have any examples of companies that do paid mapping (preferably at > scale) and do it right? > Maybe leading by example will help other mapping teams get along better with > local OSM communities? > > Michał ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Call for verification (Was: Re: VANDALISM !)
ier) a former member of the > operations working group and current co-maintainer of the rails website > posted this a year ago: > https://gravitystorm.github.io/osmf-infra-plans/ and this july the OSMF and > the operations working group announced hiring of a Senior Site Reliability > Engineer: https://mobile.twitter.com/OSM_Tech/status/1287395222847139846 > > This seems like a good move. We would benefit a lot from being able to easily > load balance and adjust VMs on our own or someone elses openstack > infrastructure where we can easily provision new servers for development or > testing when needed instead of having dedicated physical hardware servers > that causes availability issues if they break because of single point of > failures. Yes, Andy is a very smart and clever man, I've worked with him here and there over years. Be inspired by him, I am. > See also https://operations.osmfoundation.org/ > > BTW osm-fr already made this move and is mostly running VMs now and has moved > some of their VMs (heavy tile rendering) into the OVH cloud to manage their > hardware more efficiently. See > https://wiki.openstreetmap.org/wiki/FR:Serveurs_OpenStreetMap_France That's great, a white paper about this could communicate "lessons learned" and perhaps pass the torch of knowledge about how to leverage the best of these technologies for the audience(s) who could benefit. Might you write one? pangoSE, I read your unclear proto-proposal to "change naming" (to solve what problem?) and that a Reliability Engineer will be hired by the OSMF's OWG. While the latter seems unrelated, the former still remains quite vague to me and I suspect most readers of this list. If you are going to write about this more here, can you please present a clear technical specification (tech spec) of what you wish to see built? But before you do that, please first present at least one problem it might solve. Then we will better understand what you might propose. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New API suggestion: Allowing contributors to easily track their OSM-objects over time
One of the best suggestions I and others have made to pangoSE regarding this
proposal is a very strong use case or solid, easily-grasped
geographically-based examples of a problem (exclusively or largely unsolvable
in OSM today, with today's data and tools) that would make for a solvable
problem getting solved. There is a great deal of effort involved from
presenting "a solution" to the larger OSM community (first, so we understand
it, second so we might reach consensus about it, third so we might implement it
with a particular method) when no underlying problem is apparent. This is what
is meant by "a solution in search of a problem." What is it that pangoSE is so
anxious to fix that significant entanglement with a new naming system (linked
semantic wrappers) is required?
Perhaps there ARE problems that cannot be solved without such radical changes
to our naming machinery. I'm simply saying I have yet to read / hear one that
has been sufficiently articulated for me to consider this proposal further.
If problems are identified and articulated, that's a good and necessary next
step. But then so would be the greater buy-in of a well-presented proposal
that engendered sufficient discussion and perhaps eventual wide consensus to
proceed with the detailed and accepted proposal. We are a long, long way from
any of this. Let's start with what might be broken or difficult or impossible
to solve with what we have now and go from there.
I'm not saying OSM couldn't benefit by such a scheme (I keep calling it "Web
3.0-flavored" and maybe I'm right, maybe not; pangoSE chiming in about whether
his proposal and elements of Web 3.0 overlap or not is very much appreciated).
I am saying, let's have it presented to the community in a way that is usual,
potentially successful, "problem first, solution second," bite-sized in a way
that makes comprehension widely accessible and solves "something" (rather than
as it appears now: a hive of snarls that looks like deliberate obfuscation by
high priests of special knowledge). Clearly-stated concepts of what this might
solve must come first. Presenting a technical solution without articulated
problems it might solve is backwards.
OSM now has an existing "history of object edits." If you "do it right," it is
technically possible to leverage this into what you are proposing ("tracking
objects" to "follow" them?) with absolutely no change to OSM's present database
model. Maybe this is a good idea, maybe not. But pangoSE has not even
identified any costs that wold be associated with changing OSM's database
model, he simply sent us a link to it (which we can find ourselves, but thanks
for the effort).
pangoSE: please stop ignoring me in these threads. I'm extending effort to
listen, your lack of reply seems disingenuous.
SteveA
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Roadmap for deprecation of name tags in OSM
On Aug 20, 2020, at 11:58 AM, pangoSE wrote:
> ...I would go so far as to say that
>> ignoring this problem with missing references makes the names in the
>> whole database worthless to use and contribute to because it could just
>> be random joe next door sitting on a late night and adding/changing a
>> lot of crap names wi h a handful of new accounts to the database
>> objects and no-one regularly does QA-checks to see if it has any link
>> to reality.
I don't like it when people say to me about (my country, for example) "love it
or leave it" because that precludes being a good citizen and suggesting or
making IMPROVEMENTS to whatever it is that offends. However, because of the
pure falsity of the first part of the above statement ("names in the whole
database (are) worthless"), I am tempted to say exactly this to pangoSE:
simply don't use OSM if you find our data so worthless. Your problem is thusly
solved.
Or, (much better) if you are going to use them and complain (as you are and
do), propose a way to fix them. You have done so, but your proposal has
elements that are so very over-engineered and reliant upon principles of
semantic binding and tuple-/triple-stores (as I mentioned before) that are new,
untried/untested, are in the earlier stages of their development and are
largely unfamiliar to most (besides academics and first-/early-adopters) that
they need several additional "heavy lifts" associated with them to even be
considered at a beginning phase by this community. I listed some of the more
important ones in my earlier post and I could list more, but I'll refrain for
now.
What pangoSE did was not address my (I believe thoughtful and considered) post,
which looks to accommodate pangoSE's proposal over a much-more reasonable
longer-term, absolutely required given the complexity and massive kind of
changes such a proposal would entail. Rather, pangoSE "piled on" and "dug in,"
now hurling insults at the data in OSM which already exist. This behavior
(both kinds I just outlined) does not endear such proposals to the OSM
community and dulls pangoSE's effectiveness in presenting them (again, while
ignoring constructive reply).
As such, I find his proposal (and concomitant seeming lack of willingness to
listen to the feedback he solicited) to be disingenuous, especially as a result
of his petulant "sour grapes" attitude towards our data (and project, really).
>> Additionally the tags and their changes over time is really hard to
>> follow on openstreetmap.org (it is much better in JOSM though). Thats
>> bad because it means less eyeballs to make sure we have correct
>> information. A wiki-like interface for all our metadata would solve
>> both these examples and for good reasons wikidata is not the right
>> place for this data, but a community run wikibase could probably work
>> just fine.
In a community (USA-based) "Mappy Hour" I participated in last night about
doing imports well, one important question asked about imports which either are
or tend towards actual vandalism. The (correctly offered) answers are (at
least) two-fold: secondarily, there is complexity to doing imports
(especially) well that makes for a "high bar" to diminish "script kiddies" and
the unsophisticated from largely ruining our map data (though this can and does
happen) and primarily and much more importantly, there are quite a fair number
of both human eyeballs and 'bot-watching data sentinels which pay attention to
bad data entering the map. Sufficient (at least for now) enough that this
project has a handle on it. Not without somewhat pricey vigilance and
sometimes friction, but certainly much more good data enters than bad, so OSM
is "winning that race."
>> WDYT?
I told Original Poster pangoSE what I think in terms of a medium- to
longer-term approach to these sort of "Web 3.0-style" introductions to OSM in a
four-point outline in my last post to this (or a related?) thread. It is (and
remains MY turn to ask YOU, pangoSE): What do YOU think?" (about my
longer-term approach and four-point post). Can we get YOUR feedback to THAT
reply?
Let's not talk "past" each other, let's talk "to" each other.
SteveA
California
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Use of OSM data without attribution
Thanks very much you two: I've often meant to do something about alltrails' seeming / actual lack of attribution to OSM (if it exists, I haven't found it either) and something always seems to creep up and prevent me from taking action. These are most assuredly "our" (OSM's / mine, others in OSM) data. Yea: let's get this ball rolling and a proper OSM attribution! SteveA California > On Aug 19, 2020, at 2:44 PM, Clifford Snow wrote: > Hey Mike, > They definitely mention OSM, even call us a partner [1] but like you found > their basemap is definitely OSM. Instead of suggesting their users edit OSM, > they instead instruct them to email d...@openstreetmap.org, > > All Trails is located in SF but I couldn't find any listing of a leadership > team. > > Do you want to ask on Slack? Someone there might have a connection. > > > [1] > https://support.alltrails.com/hc/en-us/articles/360018930672-How-do-I-update-or-change-information-about-a-trail- > > On Wed, Aug 19, 2020 at 1:03 PM Mike Thompson wrote: > Has anyone tried contacting the AllTrails[0] people about their use of OSM > without attribution? I am not talking about the "OSM Map Layer" that they > offer, but rather the default "AllTrails Map Layer." At the very least it > appears that the trails on that layer come from OSM. I know that because I > have entered some rather obscure informal trails in OSMe, and they show up in > AllTrails just as I entered them in OSM. > Mike > > [0] https://www.alltrails.com/ (in the search box enter the name of a trail, > park, or city to see their map.) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] This needs to be voted upon. (was: Re: Separating all metadata from coordinates in OSM into a wikibase instance)
Even better stated, if pangoSE is interested in a longer-term goal (and, it truly must be this if anything at all) of moving OSM towards becoming a "full member of the semantic web," fairly large things must happen. 1) Linked data and "the semantic web" (which has been emerging since circa 2001) must become more fully-formed itself. It has been called "Web 3.0," but think about how well-defined even "Web 2.0" is today. (There will be lots of answers here, but you see my point: it's relatively early days for both). 2) Much more than a "toss a poorly-formed and poorly-stated 'what for' against the wall on the Talk board" must happen first. Inter-academic discussion, white papers, tracks at conferences, people with ideas who publish, synthesis of already-good-ideas-and-implementations in the semantic web with what OSM's longer-term goals, and much more. This is an intermediate- to longer-term proposition, I'd say five to fifteen years. (Happy Sweet 16, OSM). 3) Drop-dead-easy-for-novices integration must be nearly seamless as these begin to integrate with existing workflows in OSM. The chicken-and-egg thing going on right now is most people have never heard of Web 3.0 / the semantic web, know nothing about it, don't see it's (admittedly longer-term) benefits and so often have hostility or confusion about "why?" This might have seemed my initial position, and isn't really true, so I now clarify. 4) Real-life examples of how AI, neural networks, machine learning benefits of how linked data in a semantic web must be offered for people to see the benefits. I don't mean pedagogical aids like teaching the basics of how triple statements, literals and URIs work (though, those are important early concepts), I mean "hey, that's a really neat and powerful exploitation of why we'd bother to link data." The first examples might be geographical in nature to appear to OSM, they might not, but they should be sooner, rather than later, so people can more immediately realize benefits. There: I think I've tilled the soil a bit, and if pangoSE or somebody wants to plant seeds (again), I'd read #2 above and think much longer-term. OSM could do this, but it's going to take more than a thread on Talk and a wad tossed against a wall. And maybe a decade or two. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] This needs to be voted upon. (was: Re: Separating all metadata from coordinates in OSM into a wikibase instance)
I didn't mean to convey or imply that a vote was impending, moreso that I seriously disagree with the proposal as unneeded, unnecessary, poorly explained as to its benefits, and (as was well described before, though I paraphrase), "a ready-made answer for a non-problem." My apologies if anybody got the wrong impression that this was up for a vote. Rather, here and now it is being discussed, my "No" was merely my opinion IF it went to a vote. Better stated, I disagree with the proposal, as I see no need for it, it is over-engineered, it has no clear merit, it is confusing, it seems to be more trouble than it is worth and I feel it would chase away novice volunteers as "too complex." The consensus, with the exception of the proposer, seems 100% in line with my opinions. I do welcome more discussion, that's why we type here. SteveA > On Aug 9, 2020, at 11:01 PM, Mateusz Konieczny via talk > wrote: > > > > > Aug 10, 2020, 07:49 by md...@xs4all.nl: > On 2020-08-10 03:32, stevea wrote: > On Aug 9, 2020, at 5:29 AM, pangoSE wrote: > The discussion below spawned the following idea of migrating the whole tags > system instead. > (an over engineered proposal largely, as Frederick says and I agree > with, goosed by the "hype of linked data.") > > I politely vote "No." I don't see the merit (again echoing > Frederick). While I'm only one person and one vote and perhaps a bit > more vocal than most, I feel it important to express the opinion of > "very strongly against." > > I certainly hope that if this idea goes towards implementation that there > will be a vote first. I also don't see the merits so my vote will also be no. > Before going to vote it would need to demonstrate some sort of clear benefit > and > consensus that it is reasonable. > > Vote can be gamed in many ways, and even if that proposal somehow would won a > vote > it still would not improve it a tiny bit. > ___ > 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] Separating all metadata from coordinates in OSM into a wikibase instance (Was: Re: Roadmap for deprecation of name tags in OSM)
On Aug 9, 2020, at 5:29 AM, pangoSE wrote: > The discussion below spawned the following idea of migrating the whole tags > system instead. (an over engineered proposal largely, as Frederick says and I agree with, goosed by the "hype of linked data.") I politely vote "No." I don't see the merit (again echoing Frederick). While I'm only one person and one vote and perhaps a bit more vocal than most, I feel it important to express the opinion of "very strongly against." SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tag:railway=stop
Please click on the "View History" link of the wiki page (upper right) to see the contributors to this wiki (there are ten). You can click on their username links to contact them. SteveA > On Aug 2, 2020, at 8:25 AM, 80hnhtv4agou--- via talk > wrote: > Did someone on this List, contribute to this Wiki.? > https://wiki.openstreetmap.org/wiki/Tag:railway%3Dstop ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Editing wiki asks for confirmation code?
On Jul 26, 2020, at 12:12 PM, Skyler Hawthorne wrote: > On July 26, 2020 14:56:39 stevea wrote: >> I speculate (a bit, though I am a seasoned software quality assurance >> analyst), but I lean heavily towards Skyler's specific environment of a >> OnePlus mobile device running OxygenOS 10 and regardless of whether he uses >> Firefox or Chrome. What I find curious is that I asked Skyler whether to >> edit wiki, he chose "Edit" or "Edit Source" and he said "Neither, I clicked >> the Pencil icon." That strongly seems like something either his OS or >> browser is "doing" (javascript somewhere?) and appears to get us closer to >> finding the code-path where the "Confirmation code" dialog is thrown. > > As a software engineer, my intuition would incline me to doubt this has > anything to do with my OS. OSs don't tend to directly manipulate your web > traffic in such a way that could lead to breaking functionality in web apps > (analytics, of course, are a different matter). As for "edit" vs "edit > source", you can see for yourself that neither of those are an option on the > mobile site. and > These screenshots are from the latest version of Firefox for Android, > although the same thing happens in Chrome and Brave as well. Right, knowledge of your OS source simply better informs the browser (environment) being used in the erring environment. In a desktop / laptop / non-mobile environment (let's say macOS / Windows / Linux, running Firefox on any of those is a fair comparison), our wiki pages present "Edit" and "Edit Source" choices, provided you are credentialed on with a valid wiki.osm.org login/pw. But instead, your environment (OxygenOS 10 running Firefox) presents this "Pencil icon." Somewhere (likely wiki.osm.org) there is likely javascript (probably informed by a UserAgent string of "Firefox — OxygenOS") which is responsible for (instead) presenting the "Pencil" icon (to initiate editing) along with a subsequent code-path in the javascript of the wiki site presenting what we now understand (or strongly believe) is a broken CAPTCHA, manifesting as a "Confirmation code" dialog. That's what's broken, I (we) strongly suspect. It took a few of us to get there, but I think we have, and those responsible for the fix are now better informed to do so. Good sleuthing all around everybody, my guess is that the "mobile environment" for editing on wiki.osm.org will improve and this will eventually vanish as the defect you experienced. A bit of "more-public" QA, but QA (even good QA) nonetheless! SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Editing wiki asks for confirmation code?
I speculate (a bit, though I am a seasoned software quality assurance analyst), but I lean heavily towards Skyler's specific environment of a OnePlus mobile device running OxygenOS 10 and regardless of whether he uses Firefox or Chrome. What I find curious is that I asked Skyler whether to edit wiki, he chose "Edit" or "Edit Source" and he said "Neither, I clicked the Pencil icon." That strongly seems like something either his OS or browser is "doing" (javascript somewhere?) and appears to get us closer to finding the code-path where the "Confirmation code" dialog is thrown. Skyler, one more piece of the puzzle: your screen shot chops off the end of the web page you are browsing: it says https://wiki.openstreetmap.org/wiki/New... and then fades out. May we have the page you were trying to edit and the name of the browser you were running with this screen shot? Thanks, SteveA > On Jul 26, 2020, at 11:46 AM, Mateusz Konieczny via talk > wrote: > > Can you try viewing it in the desktop > mode or on a laptop/other full sized screen? > > Maybe mobile version is broken. > > > 26 Jul 2020, 20:13 by o...@dead10ck.com: > Right, here is a screenshot: > > https://skyler-public.s3.amazonaws.com/images/Screenshot_20200723-175602.jpg > > -- > Skyler ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries
I modestly (on occasion) set tracktype=* based on imagery, but only using higher-quality imagery where I have high confidence I can quite accurately do so. On those few occasions where I later visit the site / track and am able to glean how accurate my tagging was, I've either never had to change it to a different value or it was such a long time between setting and visiting that it was one value different (higher based on increased use, lower based on decreased use and falling into reverting to the landscape). So, done with skill, this sort of armchair mapping can be and is done accurately quite frequently, in my experience of both doing this and observing others doing this (and reading the confirmation of that here and now). That is me, your mileage may vary, though as others have said similar (that they do this), I, too, would refrain from performing a revert. If, on the other hand, you are certain that _individual_ tracks are clearly wrong, I'd say go ahead and change those one-at-a-time, but a wholesale revert, no, that seems like overkill. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries
On Jul 18, 2020, at 7:09 AM, Rory McCann wrote: > In addition (I can't find the link now but) I recall reading about the death > of a hiker or climber who used some app which used OSM data, and the app > didn't distinguish between track_types (or there was no track_type data for > that route), so the hiker presumed it was OK to go on, and subsequently died. Let us be clear as crystal as we pause to realize the key part of this: "so the hiker presumed it was OK." The hiker made that choice. Any assumption that OSM has ANYthing to do with a subsequent death is specious and only that: an assumption. No, maps don't "make people" do foolish things. Yes, people do foolish things, by their own volition. Not because "the GPS made me do it" or "the map is responsible" (somehow). OSM makes no warranties as to fitness or merchantability for any particular purpose. Do I (we) really need to say this? It's sad if we do. I recently had someone from my local Land Trust imply that because I entered trails under development from their public map (and tagged access=no) that somehow OSM was responsible for increased trespassing. Ridiculous. Maps don't make people choose to break the law, people do. I set him straight and we get along fine. SteveA California ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bridge area construction
On May 5, 2020, at 3:29 PM, Rafael Avila Coya wrote: >> I use the lifecycle prefixes a lot, specially for shops, restaurants and >> others that close. Like for example disused:shop=* or >> disused:amenity=restaurant, etc. The abandoned:*=* prefix is also quite >> useful. This is terrific, however I ask that caution be used with some of these, in particular abandoned and with railways. There is such a tag as railway=abandoned and some renderers use it (OpenRailwayMap) and others don't (Carto). It would be "less correct" to use the tag abandoned:railway=rail whereas tag railway=abandoned is "perfectly correct." There are other examples. The upshot is to please do your best with wiki research and perhaps some taginfo and / or OverpassTurbo queries. That is simply a good idea if you really don't know how to tag and really want to tag "more correctly." (And hasn't this been true for all of us, to some extent?!) Thanks for reading, SteveA California ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] trace and signs
I agree that not all signs should be mapped, and exactly as Warin describes them here. I DO believe that guidepost, map and information signs (as our wiki describes and as I did earlier in this thread) SHOULD be mapped. As I re-read 80hnhtv4agou's original post, it looks like he wants to map (the location of?) a sign that names a park (as a node, he called it a "point," while "node" is the more correct OSM term). As Warin says, I wouldn't map this particular sign as a node, I would simply map the name of the park (on the polygon that represents it). Although sometimes, a park is initially entered in OSM as simply a node, before its boundaries as a polygon are well known (then they are later, better mapped). This is an OK thing to do in the early stages of a park "entering" OSM's database, and the location of the sign that announces the name of the park is as good a place as any to enter this node, along with a name=Park Name tag on that node. SteveA > On Apr 24, 2020, at 5:01 PM, Warin <61sundow...@gmail.com> wrote: > > On 25/4/20 2:01 am, 80hnhtv4agou--- via talk wrote: >> if in the ID editor there are points for picnic tables, what about a point >> tags as a sign. > > > What sort of 'sign'? > > > Mapping a sign that says the road has a name? I'd not do that. I would tag > the road with the name. > > Mapping a sign that says a city has a name? I'd not do that. I would tag the > city with the name. > > Mapping a sign that says a building has a name? I'd not do that. I would tag > the building with the name. > > > Not all signs should be mapped. > > > > ___ > 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] trace and signs
Yes, you can do this. It is especially helpful for "info signs" that might have a map, or information on wildlife or specific dangers at the park (toxic plants, poisonous snakes, steep cliffs, slippery rocks...). You can tag this with tourism=information, information=board. There is also information=guidepost, information=map and information=route_marker; please see https://wiki.osm.org/wiki/Tag:tourism%3Dinformation . SteveA California > On Apr 24, 2020, at 9:01 AM, 80hnhtv4a...@bk.ru wrote: > > if in the ID editor there are points for picnic tables, what about a point > tags as a sign. > > > Thursday, April 23, 2020 11:13 PM -05:00 from stevea > : > > Y'know, I might suggest some wiki-reading. Perhaps 80hnhtv4agou takes a look > at our wiki for leisure=park (messy as it has been) and how the tags all glom > together: tagging leisure=park and name=Fred's Park will cause our "current" > Standard renderer (Carto) to display this with a minty-green and > slightly-italicized typeface font to be selected to display these attributes > (named park) together. > > If 80hnhtv4agou is language-challenged (hey, that's OK), please offer us a > translation partner to his/her preferred dialect. Much can be and is arranged > to "simply work" in OSM. This, too. An interesting register, this. > > SteveA > > ___ > 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] trace and signs
Y'know, I might suggest some wiki-reading. Perhaps 80hnhtv4agou takes a look at our wiki for leisure=park (messy as it has been) and how the tags all glom together: tagging leisure=park and name=Fred's Park will cause our "current" Standard renderer (Carto) to display this with a minty-green and slightly-italicized typeface font to be selected to display these attributes (named park) together. If 80hnhtv4agou is language-challenged (hey, that's OK), please offer us a translation partner to his/her preferred dialect. Much can be and is arranged to "simply work" in OSM. This, too. An interesting register, this. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] remove the suggestion to credit "contributors"
On Apr 20, 2020, at 2:02 AM, Jiri Vlasak wrote:
> +1. I feel that "contributors" should stay in the credit.
+1 here, as well. I correctly and not with excessive overt pride sit up a bit
straighter and feel a sense of community, satisfaction and even dignity every
time I see "contributors" in OSM's copyright statement. ("That's millions of
us doing good work because we love this kind of mapping, including ME!") This
recognition is important. This is one of the best reasons I contribute to our
map and I am certain that I'm not alone in these feelings. (For every +1 you
see here, there are hundreds, thousands, I'm pretty sure millions that you
don't see).
Sure, the results are a darn good map which gets better every hour of every
day. But crediting "contributors" is a critical component of that happening.
Remove it and you remove my sense of belonging to this mapping community, so,
the growing chant from the masses should be clear: don't do that. Changing
the rules (licensing, recognition, rights...) in the middle of the journey is
the quickest way to discourage more of us to drop out of this fine project.
SteveA
California
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Replication errors
Sarah, thank you! You are really "on it!" SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Replication errors
If I had to guess, > On Apr 15, 2020, at 11:10 PM, Andrzej Kępys wrote: > ... > Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run > INFO: Pipeline executing, waiting for completion. > Apr 16, 2020 8:05:03 AM > org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager > waitForCompletion > SEVERE: Thread for task 1-read-replication-interval failed > org.openstreetmap.osmosis.core.OsmosisRuntimeException: Unable to parse xml > file this looks like a severely starved read-data pipeline, which is very often caused by overloaded servers not being able to keep up with serving data to too many read requests. Given how many people are overloading OSM's tile servers, other servers are also likely heavily-loaded or overloaded. Many, (billions) of us ARE, after all, in "COVID-19 lockdown" and find mapping on the 'net to be a soothing and worthwhile activity while cooped up. I had this happen earlier today on Lonvia's (?) Nominatim server(s), something I've never seen before. I'd "do your best" to discover a contact for the particular server (osmosis.openstreetmap.org is a guess, but it is a good start) and ask if it is experiencing overload conditions right now. It likely is, that likely explains the error(s) you see. However, I could be wrong. Check our "stats" page, https://wiki.osm.org/wiki/Stats which can offer helpful insights to user, database and server activity, or lead you to places where you might find what you're looking for. Good luck, have fun mapping, be as gentle as you can be on OSM's servers, SteveA California ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Help needed: OBS tutorial for Windows and Mac
I added a link to Frederik's page for the "download and installation" page for OBS, which allows any supported flavor of OBS for Windows, macOS or Linux to be downloaded and installed. I took a brief look at the Linux-based tutorial that Frederik wrote (nice! and thank you!) and believe it will work for macOS and Windows, though it depends on how the UI/UX differs between builds. I'd suspect "not very much, if at all." Again, if Christine and/or the program committee have any "themed" collateral they'd like to see (like a SotM logo or video bug) in some/most/all submissions, a link to those on Frederik's user-space page is as good a place as any to submit these. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Help needed: OBS tutorial for Windows and Mac
Coming from someone with cross-platform experience and technical writing skills similar to what I understand Cassandra is asking, I'd say a good start would be a tutorial on how to INSTALL the different flavors of OBS for each supported operating system (Windows, Linux, macOS). Make a pointer to the "install page," instruct that you can choose three (or more, sometimes a different version is required for an older OS, like Windows 7 and 10 might have different versions, or 10.15 being 64-bit only, maybe 10.14 down 10.6.8 would be supported for a 32-bit version, or "yes on Ubuntu of a particular version or later, but if you run Red Hat, you must have blah, blah"...) installer packages. Then give instructions on each, even if it is "double-click the installer" (or invoke it from a command line like "this") and watch as people play with it and begin to make submissions of completed (or partially completed) presentations. If the software has some built-in Help System (I haven't looked), installation instruction may be all that's required. They are certainly a good start, if they don't already exist on the OBS download page (I haven't looked). Guidelines (as to length) or templates (like a themed border-slide that has the SotM 2020 logo, for example) are helpful things to add which promote consistency, but these are not absolutely required. Doing my best to help, SteveA California > On Apr 5, 2020, at 12:33 PM, Frederik Ramm wrote: > > Cassandra, > > On 4/5/20 21:28, Cassandra McCarthy wrote: >> I have a Windows install. Should I basically recreate the linked >> tutorial, but for Windows? > > I cannot say how big the differences are. If it's "basically the same" > in Windows then it might be better to add comments to the existing > tutorial (I did it in my user space because I wasn't sure what the final > location should be - don't shy away from editing in my user space). If, > on the other hand, things are vastly different on Windows to the point > that the tutorial I made will confuse people more than it's good, then > by all means do a separate tutorial! > > 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 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New status for keys/tags in the wiki: "import" for tags that are only imported from an external database
On Mar 24, 2020, at 7:42 AM, Joseph Eisenberg wrote: > After the discussion, the status "import" should be limited to tags > that are clearly imported from external sources. Common examples are > external references, IDs, source tags, and specialized import-only > tags (e.g. "tiger:*"). Most of these don't have a wiki page. I agree that "status import" should be limited as stated. Providing a wiki page about tags which are imported seems like something we can all agree is a requirement, something that must result from a "formal" import that gets done "formally." > I've added status=import and tagged a few keys which are documented: > > https://wiki.openstreetmap.org/wiki/Category:Key_descriptions_with_status_%22import%22 > Also see update of https://wiki.openstreetmap.org/wiki/Approval_status > with this value. Both are helpful, thank you! SteveA California ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import
"Subtleties" not "subtitles." Dang auto-correct! Also, I was sloppy with "data are plural, datum is singular." Roland's "true, excellent point" (period, not colon) is that sometimes this becomes a "cost-benefit evaluation" where the trouble to "fix" (modify) data may likely be higher-cost than the benefit of what might be determinable directly from the data (anyway, presently). SteveA > On Mar 18, 2020, at 10:52 PM, stevea wrote: > > Even the "let's not misunderstand" posts might even contain slight > misunderstandings. As Roland mentions tiger:cfcc tags, there is an argument > (and documented wiki) that suggests they might still yield some underlying > structure of the TIGER rail import in the USA which can provide useful data > (in constructing route=railway relations, for example) still today, even as > they have become somewhat smeared since their import. It is virtually > impossible to recognize all such subtitles of all such structured data that > is now in OSM. To say "this import seems to have 'grey' (old, misunderstood, > seems to be 'noise in place') data, we should structurally treat it like x, y > and z" REALLY must have some deep treatment about what these data were, are > and might be before some wholesale data manipulation occurs. > > I'm not saying some of these (clean up our data sub-projects) aren't good > ideas, just that we MUST look at the whole iceberg rather than only its tip. > Usually, what appears to be is only the tip and the iceberg is bigger than > one might realize. > > SteveA > >> On Mar 18, 2020, at 10:37 PM, Roland Olbricht wrote: >> ..."stale": Tags that came with an import, are not, and can not be used by >> general mappers, and are not expected to be updated. "tiger:cfcc" is >> currently the most numerous. The low number of values of "tiger:cfcc" >> makes it unlikely that it is carrying any meaning. >> >> Another final question is whether it makes sense to refine the system at >> all. Much of the information of the tagging classes is available via >> taginfo, and some more can be automatically computed from the database, >> although it is it done today. Having this is as explicit information >> instead is the either redundant (if in line with actual database >> content) or misleading (if in contradiction to the actual database content). > > This is a true, excellent point: ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import
Even the "let's not misunderstand" posts might even contain slight misunderstandings. As Roland mentions tiger:cfcc tags, there is an argument (and documented wiki) that suggests they might still yield some underlying structure of the TIGER rail import in the USA which can provide useful data (in constructing route=railway relations, for example) still today, even as they have become somewhat smeared since their import. It is virtually impossible to recognize all such subtitles of all such structured data that is now in OSM. To say "this import seems to have 'grey' (old, misunderstood, seems to be 'noise in place') data, we should structurally treat it like x, y and z" REALLY must have some deep treatment about what these data were, are and might be before some wholesale data manipulation occurs. I'm not saying some of these (clean up our data sub-projects) aren't good ideas, just that we MUST look at the whole iceberg rather than only its tip. Usually, what appears to be is only the tip and the iceberg is bigger than one might realize. SteveA > On Mar 18, 2020, at 10:37 PM, Roland Olbricht wrote: > ..."stale": Tags that came with an import, are not, and can not be used by > general mappers, and are not expected to be updated. "tiger:cfcc" is > currently the most numerous. The low number of values of "tiger:cfcc" > makes it unlikely that it is carrying any meaning. > > Another final question is whether it makes sense to refine the system at > all. Much of the information of the tagging classes is available via > taginfo, and some more can be automatically computed from the database, > although it is it done today. Having this is as explicit information > instead is the either redundant (if in line with actual database > content) or misleading (if in contradiction to the actual database content). This is a true, excellent point: ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import
See, data always have a backstory. Thinking you know what it is, or that you can improve upon OSM by erasing existing data that has a backstory, hmmm, give that one a good, long think first before you do anything. Discuss with others, research, think about past, present and even future data/tagging schemes that might truly improve what you attempt to improve. Doing this is complex and deserves complex treatment, not a gloss-over and quick action. SteveA > On Mar 17, 2020, at 4:38 PM, stevea wrote: > > I would like to stress once again how easily it is for intended semantics of > what is meant to be tagged, "improve-tagged" or "tag-modernized so that > people understand the historical context of this tag" to diverge from the > semantics that OTHER volunteers / contributors to OSM glean from these. It > is SO easy for these to be far apart and people to misunderstand one another. > > This entire endeavor is fraught with peril and is one of the most slippery > and dangerous (in the sense of hurt feelings due to misunderstandings, > usually unintentional) in any scheme that has to do with "tagging," as in OSM > with our tags (and their meant-to-be-static, though actually change through > time) semantics. > > Please, let's better understand the very wide aspects of what's going on > here: people invent a tag to mean "something" and perhaps it does for a > while, but it might get stretched with time and might morph to something > else. And/or other tags emerge that better or "more newly" describe a scheme > to tag. Meantime, there are rendering issues (some positive, some negative) > happening in parallel. Even as people are mostly well-intentioned, this > process (especially as the project gets more mature and stretches across > generations of this happening, each cycle might be years or a decade) really > is complex and gives rise to all kinds of tangly, snarly misunderstandings. > Tread lightly, be cautious, try to be open-minded, have both a historical > understanding of how "meanings change over time" (even as we wish they > didn't" and "renderers change over time" (not always exactly in-line with > tagging schemes) as well as a willingness to expand context to the future. > > And perhaps several other things I'm forgetting to mention... and we MIGHT be > able to better solve these issues. We can solve them, we have to be smart, > patient and knowledgable about our past, looking to the future and aware of > how things drift and evolve. That's tough, but doable. > > Whew! > SteveA > >> On Mar 17, 2020, at 4:17 PM, Joseph Eisenberg >> wrote: >> >> Unlike some of those who responded, I was not intending this status to >> be a "mark of shame", but rather informative. >> >> As mentioned, some imported tags like "gnis:feature_id=*" are useful >> to keep the Openstreetmap database object directly linked to an object >> in an external database. >> >> That's why I am not suggesting the use of "deprecated" or "obsolete", >> since these tags should not necessarily be removed. >> >> The main reason to mark them is so that mappers and database users >> will understand where the tag came from, and it may suggest that >> mappers will not want to add these tags to objects in the future, >> unless they are also importing features from the same source. >> >> Besides the tags mentioned above, I was thinking about tags like >> "object:postcode=" and "object:housenumber" - this tag is only used in >> Germany on "highway=street_lamp" features which appear to have been >> imported mostly in 2015: http://wiki.openstreetmap.org/wiki/Key:object >> and see taghistory: >> https://taghistory.raifer.tech/#***/object:postcode/ and >> >> So, though the usage numbers are moderately high, it is helpful to >> know that these tags are not really being used, except in that >> particular context. Apparently it makes sense in the context of the >> addressing system there, at least according to the mappers who >> imported the objects. >> >> If a tag which was first used in an imported then becomes popular and >> used frequently by. mappers for new or updated features, then it could >> change to "in use" or even "de facto", just like a "draft" or >> "proposed" tag can change status due to usage over time. >> >> So, just like the status "draft", the status "import" would be a hint >> for mappers and database users, but would no
Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import
I would like to stress once again how easily it is for intended semantics of what is meant to be tagged, "improve-tagged" or "tag-modernized so that people understand the historical context of this tag" to diverge from the semantics that OTHER volunteers / contributors to OSM glean from these. It is SO easy for these to be far apart and people to misunderstand one another. This entire endeavor is fraught with peril and is one of the most slippery and dangerous (in the sense of hurt feelings due to misunderstandings, usually unintentional) in any scheme that has to do with "tagging," as in OSM with our tags (and their meant-to-be-static, though actually change through time) semantics. Please, let's better understand the very wide aspects of what's going on here: people invent a tag to mean "something" and perhaps it does for a while, but it might get stretched with time and might morph to something else. And/or other tags emerge that better or "more newly" describe a scheme to tag. Meantime, there are rendering issues (some positive, some negative) happening in parallel. Even as people are mostly well-intentioned, this process (especially as the project gets more mature and stretches across generations of this happening, each cycle might be years or a decade) really is complex and gives rise to all kinds of tangly, snarly misunderstandings. Tread lightly, be cautious, try to be open-minded, have both a historical understanding of how "meanings change over time" (even as we wish they didn't" and "renderers change over time" (not always exactly in-line with tagging schemes) as well as a willingness to expand context to the future. And perhaps several other things I'm forgetting to mention... and we MIGHT be able to better solve these issues. We can solve them, we have to be smart, patient and knowledgable about our past, looking to the future and aware of how things drift and evolve. That's tough, but doable. Whew! SteveA > On Mar 17, 2020, at 4:17 PM, Joseph Eisenberg > wrote: > > Unlike some of those who responded, I was not intending this status to > be a "mark of shame", but rather informative. > > As mentioned, some imported tags like "gnis:feature_id=*" are useful > to keep the Openstreetmap database object directly linked to an object > in an external database. > > That's why I am not suggesting the use of "deprecated" or "obsolete", > since these tags should not necessarily be removed. > > The main reason to mark them is so that mappers and database users > will understand where the tag came from, and it may suggest that > mappers will not want to add these tags to objects in the future, > unless they are also importing features from the same source. > > Besides the tags mentioned above, I was thinking about tags like > "object:postcode=" and "object:housenumber" - this tag is only used in > Germany on "highway=street_lamp" features which appear to have been > imported mostly in 2015: http://wiki.openstreetmap.org/wiki/Key:object > and see taghistory: > https://taghistory.raifer.tech/#***/object:postcode/ and > > So, though the usage numbers are moderately high, it is helpful to > know that these tags are not really being used, except in that > particular context. Apparently it makes sense in the context of the > addressing system there, at least according to the mappers who > imported the objects. > > If a tag which was first used in an imported then becomes popular and > used frequently by. mappers for new or updated features, then it could > change to "in use" or even "de facto", just like a "draft" or > "proposed" tag can change status due to usage over time. > > So, just like the status "draft", the status "import" would be a hint > for mappers and database users, but would not suggest that the tag > needs to be removed, and it might change status in the future based on > use by mappers. > > -- Joseph Eisenberg > > On 3/18/20, Jmapb wrote: >> On 3/17/2020 10:52 AM, Wayne Emerson, Jr. via talk wrote: >>> However, among your examples you cite "gnis:feature_id=*" The wiki >>> page for this key notes: >>> "Unlike other imported tags such as gnis:created=* and >>> gnis:import_uuid=*, gnis:feature_id=* is meaningful beyond the import. >>> In fact, some mappers actively add gnis:feature_id=* to features to >>> cite a verifiable source for the POI's existence or its name." >> >> Agree with clemency for gnis:feature_id -- it's handy to be able to >> crossreference features with the
Re: [OSM-talk] fixme=name
There is a lot going on in this topic: primarily, a fairly large, potentially unknowably large semantic of meanings the author of a fixme tag meant when created. Let's be careful as we interpret these. Assumptions by the recipient of that tag should be cautious, lest they wrongly predict the intent of the author. I find fixme most useful when it paints a bright line forward of what needs fixing in a map datum (a node with tags, for example). If the fixme tag is poorly written, ambiguous or the like, please, (without complaint, please) do your best to interpret how it was meant to be helpful and improve the tags (location, whatever) of the datum. Data entered into our map (especially by beginners or maybe as part of a quickly-assembled HOT group, for example, which might include novice mappers) are not always perfect. They should be at the very least "good," hopefully very good or excellent and during some happy fraction of data entry might even be called "perfect." Yes, some OSM data remain at Version 1 of their History, they were that good at entry, "no improvements required" since. Data in our map change, they live. The lifecycle sometimes includes "fixme" tags. Such tags, such a part of being in the data lifecycle means we must learn to do our best at improving these as we see them. Discussion like this helps, but I feel sure "these should have entered perfectly to begin with" is a downward spiral I don't want to walk. Let's improve data, even as we talk about how we improve data while we realize people can "mean" a lot of things with sloppy (yes, correct, if a bit harsh) data entry. Cut this sloppiness a bit of slack, do your best to understand what they meant by that and improve what you can. Then, our map continues to grow better (in both data and data quality). Yes, this is a version of "perfection is the enemy of the good." I know I walk right up to a line here of "don't put junk into our map, or stuff that'll get crufty over time" and yes, that is a real concern, I realize. SteveA > On Mar 12, 2020, at 4:29 PM, John Whelan wrote: > > But then you're often talking about a HOT mapper who might not have done any > mapping for three years. > > I must confess when validating HOT projects if I saw a mapper had done > something glaringly wrong and it was more than a week before noting the > response rate to a changeset message was less than 1% I may have simply > corrected the work. > > I haven't been on the ground in Africa but I suspect the number of villages a > kilometre apart connected by a one kilometre motorway is not high. If have I > reclassified someone's private motorway I apologise. > > I think we have talked around the subject enough and it should be left to the > local mappers to decide what to do. > > Thanks John > > Mateusz Konieczny via talk wrote on 2020-03-12 7:17 PM: >> >> >> >> Mar 12, 2020, 23:54 by dieterdre...@gmail.com: >> >> >> sent from a phone >> On 12. Mar 2020, at 17:42, Marc M. wrote: >> >> we may delete all fixme=name for all object without a name tag >> >> >> I agree that fixme=name for missing names is pointless and could be removed >> (although Andy has a point about not knowing someone’s workflow, so for >> safety you could spare those added in the past 1-3 months). If there are >> other questions concerning the name it would obviously have been better if >> they had been more explicit about these potential problems in the fixme tag, >> but still, if someone has added a fixme=name on an object with a name we >> should keep it. >> Though unspecific fixme=name is not very useful, I would ask in changeset >> that added this >> what exactly is wrong/suspicious if I would encounter it during editing. >> >> And yes, fixme=name on object without name is likely completely useless. >> But I would also consider asking people adding it whatever it is used in any >> way. >> >> >> ___ >> talk mailing list >> >> talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk > > -- > Sent from Postbox > ___ > 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] Announcing Daylight Map Distribution
On Mar 10, 2020, at 3:17 PM, Michal Migurski wrote: > Thanks Mikel for your followup! > > In response to your recommendation that we publish what *didn't* make it > through the filter process, we released an OSC diff file: > > > https://daylight-map-distribution.s3.amazonaws.com/pbf/planet-2020-03-06_v0.1.osc.bz2 > > At this early stage of trying to determine what’s useful for the community, > it’s pretty raw. The OSC does not yet differentiate between things we > filtered out categorically because we don't show them on our maps, vs. things > we filtered out individually because we found a problem with them. Individual > tree nodes are an example of the former: they don't get shown or labeled so > they’re not in Daylight. > > I appreciate everyone’s questions about this data release. The FB team behind > Daylight and our other mapping efforts is well aware that OSM is a tough and > curious community! > > -mike. I realize that OSMCha (as Mapbox describes its use) and the compressed planet file extract (as Facebook publishes and begins to describe its use) are (respectively) ways to "flag changesets/features with reasons" and are characterizable as in "early stages of trying to determine what's useful for the community (pretty raw)." I'd call both of these a reasonable start, especially as Mapbox's pipeline seems a bit further along in its development and Facebook's data is in an early state, still needing more feedback from the community. I encourage the community to provide this feedback, perhaps on an ongoing/continual basis, and thank both Mapbox and Facebook (well, Mikel and Michal) for their participation and good communication here. Good QA improvement can and does work: in a project like OSM with corporate participants endeavoring on major sub-projects, it is usually based on very open communication with very wide community like this. Yay! (And conversely, as these get better established and "tightened up" into what the community expects and can participate in improving, the volume knob here can be turned down as these discussions don't have to be quite so public). SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Announcing Daylight Map Distribution
Similar to what Mikel described as "what Mapbox has set up," I humbly suggest that Facebook offer the wider OSM community (here on OSM-talk is a good place to do so) something similar. As we (here) better understand what, exactly, Facebook's QA processes are as they use (and improve) OSM data, the wider OSM community can offer a critique of them, suggest more robust improvements to workflow (if we see that there are any to offer) and everybody wins: both OSM and Facebook together. If "better data" are the ultimate goal (and aren't they?!) there should be no argument with these suggestions. Facebook might say "our QA process are proprietary" (and they'd be correct), but in the spirit of "Open" being OSM's first name, I hope not. I say this as a professional software and data quality scientist/engineer/analyst (since the 1980s) and long-time contributor to OSM (for most of its history). It is nearly always true that improvements to "quality process" can be made, especially as these are opened up to the wider scrutiny of a knowledgable and experienced community, as we are here. Indeed, "quality process improvement" is itself correctly a near-constant process. Whether at the level of individual contributor or corporate behemoth, such wider scrutiny in a project like OSM should be par for the course (expected, "business as usual"). SteveA California ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Planet torrents...
When I saw these (planet file sharing, torrent generation, scripting-sharing tweaking) efforts began (and were mentioned here) about a month ago, these are precisely the data I was looking for as they evolved: seed dl/ul ratio, dump performance / timings... . Thank you, Christian, nice reporting and I'm sure widely appreciated (not only me). SteveA California ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects
I believe I speak for many, most, or even all of us here (except Tomek) that "this is a settled matter." SteveA > On Feb 25, 2020, at 12:44 PM, Tomek wrote: > > W dniu 20-02-25 o 19:57, Maarten Deen pisze: >> You are forcing (or are trying to) me and a lot of others to learn >> Esperanto. That's just the same. More people speak English than Esperanto. >> Then what is the more logical choice? > Esperanto estas pli logika por internacia komunikado pro ĝia neŭtreco kaj > simpleco. > Esperanto estas pli logika por internacia komunikado pro ĝia neŭtreco kaj > simpleco. > > W dniu 20-02-25 o 19:57, Maarten Deen pisze: >> If you don't want to read english and you have no problem putting every mail >> into a translator, than why not do that? >> Just don't get mad if other people do not want to do that. You can't force >> other people to use a translator just because you choose not to write in >> English. > Tiu ĉi rilato estu simetria: mi ne devigos al aliaj uzi Esperanton aŭ la > polan, aliaj ne devigos al mi uzi la anglan. > This relationship should be symmetrical: I will not force others to use > Esperanto or Polish, others will not force me to use English. > > W dniu 20-02-25 o 19:46, Yves pisze: >> This discussion is hopeless, and 90% off topic. >> The only outcome of discussing languages here is that the status quo of >> using an English name for oceans remains. Given the amount of words spent >> off of this matter, this status quo is slowly reaching consensus, keep on! > Mi akordas kun vi, ke la diskuto iĝas en malĝusta direkto, anstataŭ pri nomoj > de internaciaj objektoj, ni diskutas pri lingvo de la diskuto. Pardonu, kial > nomoj de oceanoj estu en la angla, sed ne en la pola? > I agree with you that the discussion is going in the wrong direction, instead > of the names of international objects, we are discussing the language of the > discussion. Sorry, why should ocean names be in English but not in Polish? > > W dniu 20-02-25 o 19:46, Mario Frasca pisze: >> automated translations? they go through English, mostly, and they fail >> terribly when doing two passes. some languages are still beyond the reach >> of most translation algorithms. I would NOT rely on them. > Mi eblas komunikadi kun vi uzante tradukilojn Google kaj Yandex. > I can communicate with you using Google and Yandex translators. > > W dniu 20-02-25 o 19:59, Mateusz Konieczny pisze: >> Are you serious? >> >> "almost no one" is a weird claim, >> given that over 2 000 000 000 people >> managed. >> >> Over 600 000 000 did this as a >> foreign language. >> >> (And it is not like pronunciation is >> used on text-only mailing list!) > Infanoj pasigas kelkajn jarojn por lerni (kun mizera sukceso) la anglan, tiun > tempon ili povus pasigi por lerni Esperanton kaj aliajn profitdonajn > povsciadojn. Mi lernis ĝin por naŭ jaroj, povas lerni anglan Vikipedion, > teĥnikajn artikolojn, sed ne povas paroli kaj aŭskulti filmojn en ĝi. Post > lerni Esperanton en unu jaro mi sentas min pli lerta en ĝi ol en la angla. > Children spend a few years learning English (with disastrous success), this > time they could spend learning Esperanto and other profitable knowledge. I > have been learning it for nine years, can learn English Wikipedia, technical > articles, but cannot speak and listen to movies in it. After learning > Esperanto in one year, I feel more fluent in it than in English. > > W dniu 20-02-25 o 20:22, stevea pisze: >> I suggest we begin to diminish the importance of this thread being hijacked >> by Tomek's topic by not responding to him (with our reasonable >> disagreements), as we have repeated our points so many times that seems to >> be the only thing left for us to do. Perhaps that is the only reason Tomek >> persists: simply to argue. Enough already. Without any oxygen in the >> room, the flame can no longer burn. Perhaps we simply utter a brief phrase >> like "it's a settled matter" if the topic of Esperanto vs. English returns >> here. > MI NE VOLAS KVERELI, mi nur volas interkonseton! Mi volas montri al vi ke > angla ne estas la plej bona lingvo por komunikado, estas maljusta. > I DON'T WANT TO COME, I just want a deal! I want to show you that English is > not the best language for communication, it is unfair. > ___ > 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] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects
On Feb 25, 2020, at 11:43 AM, Mario Frasca wrote: > > On 25/02/2020 14:22, stevea wrote: >> as an emerging (emerged?) consensus we seem to be leaving the names of >> international objects in English > > I wish to express my disagreement. > > and I will give more examples, from openstreetmap.org, "the" map. > > Gulf of Venice; Gulf of Trieste; unlabelled Mare Adriatico; North Sea; > unlabelled Ostsee; unlabelled Canale di Otranto; Balearic Sea (you're kidding > me!); unlabelled Mediterranean; unlabelled Red Sea; unlabelled seas and > straits West of Japan; unlabelled Bering Strait; > > so while I do feel uncomfortable seeing English labels between Venezia, > Trst/Trieste and Istria, I am even more uncomfortable with the absence of > labels elsewhere. OK, Mario. Evidently there is more to say about this. Let us continue. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects
This discussion is tedious and exhausting. We've paid out miles and miles of patient listening to Tomek's points, politely (and unanimously) disagreed with him, yet still, he persists in thrusting his polemic upon a communication channel intended to discuss open source mapping of a particular linguistic register (the OSM talk page, where "which language should / do we use?" is a completely settled question, not an open one). I believe I speak for many of us when I say I no longer wish to entertain "linguistic imperialism" discussions. I suggest we begin to diminish the importance of this thread being hijacked by Tomek's topic by not responding to him (with our reasonable disagreements), as we have repeated our points so many times that seems to be the only thing left for us to do. Perhaps that is the only reason Tomek persists: simply to argue. Enough already. Without any oxygen in the room, the flame can no longer burn. Perhaps we simply utter a brief phrase like "it's a settled matter" if the topic of Esperanto vs. English returns here. Let's return to discussing mapping. I agree: as an emerging (emerged?) consensus we seem to be leaving the names of international objects in English, with any additional language welcome to be added as a name:xyz (language suffix) tag. We can also use the int_name tag, which our wiki has documented for quite some time as "International does not (necessarily) mean English." I remain (barely) in a listening mode to other suggestions, but they are disappearing from this conversation like the light in the sky after sunset. "It is what it is." (It's a settled matter). SteveA California ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects
On Feb 23, 2020, at 3:01 PM, Tomek wrote: > > ...a sam promujesz jakiś nielogiczny twór promujący tylko jeden naród - > Anglików. (...you promote some illogical creation promoting only one nation - the English.) This simply is not true. The "creation" is perfectly logical, as the origin story of OSM beginning in England is repeated / explained yet again to positive effect, and it does not promote "only one nation," rather, it promotes one language. A language spoken as a second language in more countries than any other: what might be called a de facto lingua franca around the world, although I and others certainly recognize how this might be seen as hegemonic and / or even more offensive, as in "language imperialism" (it isn't, but many recognize how it is easy for many to see it that way). What is meant by "de facto" is that it is "in fact" used so extensively: well over half the countries on Earth, with over 1.2 billion speakers — 1 out of 6 humans and easily the most spoken and widespread language on the planet. (That is simply a fact). You might say Mandarin and Cantonese are spoken by about as many, but really, largely speaking only in China, and so not nearly as dispersed all over the globe as is English. (This may change in the future with China's apparent 21st-century ascendency, but let's not get ahead of ourselves). Tomek, it should be as clear to you now as it is to many of us here that your use of Esperanto and Polish, as well as your insistence that widespread usage of English in OSM diminish to your specification has failed to gain traction. May we ask you quite directly to cease with this campaign of yours, please? I agree with Alan M. that it has become tedious, if not actually beyond that. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Is there some existing detailed tutorial directed at complete newbies? Describing how to add various features?
I, too, have noticed this "apparent deprecation" of the importance of our wiki and would like to see it remedied. Not only do I find the wiki drop-dead easy to search and "read up on" how to do something in OSM (as in "this is how we already do it" or "this is how far along we are on a particular (local, specific) endeavor or sub-project") — encyclopedia / wikipedia style — but there is a comparatively low bar of entry should even a novice user wish to change / update a wiki that is already substantially written, but can benefit by a casual user coming along and discovering it needs only a slight update to be ship-shape. In my opinion, this makes our wiki one of the most powerful reference and communication vehicles in the project, as even for novices, it is not only highly accessible and helpful, but encourages simple (or yes, even complex) contributions which strengthen it. Let's continue to "market" our wiki (to newer users, especially) as the very potent resource that it is. If this means improvement in how we point (newer) users to our wiki, let's do that. If there are other, more noticeable or visible places where we can do this but now do not, let's fix that so we do. SteveA California > On Feb 22, 2020, at 2:21 PM, Clifford Snow wrote: > > > > On Sat, Feb 22, 2020 at 12:49 PM Wayne Emerson, Jr. via talk > wrote: > The OSM World Discord server usually has people on that can answer basic > questionshttps://discord.gg/q6HnfNZ > Doing the iD tutorial teaches the basics and is easy to learn. One can learn > the basic tags by using the presets found using the iD search box. Tagging a > basic individual object can be learned from the wiki. > > The iD tutorial is very helpful for new mappers. Completing the tutorial only > takes a few minutes. Unfortunately only a small percentage start or complete > the tutorial. Since the first of the year of the nearly 6800 new mappers > only 29% complete the entire tutorial. While it doesn't get at complex edits, > it does cover what I see a typical new mapper contribute. > > However some tagging situations are more complex, like how to tag a school > (What tags go on schoolyard vs. the building) or bus routes, or admin > boundaries, etc. There are some nice guides buried in the wiki but it can be > difficult for a beginner to wade through all the component tags before > finding a guide to the whole. This can be discouraging to a new mapper. Even > more so when you do find a guide, for example, on tagging bus routes but then > not being sure if its the new scheme or the old scheme and so many > contradictions can make people give up. > > I agree with this assessment. Just yesterday a new mapper added a new park, > unfortunately one already existed. Because it was a complex multipolygon I'm > sure they did realize it. > > > > Wiki cleanup & a front page link to an index of authoritative & current > tagging guides for complex entities would be nice. Maybe call it "Special > Mapping Guides" > > Creating nicer guides would be nice, but my experience, most new mappers > don't start looking at the wiki until much later. I do point to wiki articles > when giving feedback with the hope they will read it. > > One of the other problems facing new and occasional mappers is the complexity > and density of many of the cities. When I started in the US I was able to > add glaciers and parks with a clean palette to work from. Today when mapping > we have unlike features joined, complex relations, streets with lane counts > and turn lanes, streams, culverts, sidewalks, buildings, etc.. It's much > harder to for a new or occasional mapper to contribute without problems. > > Some might suggest we force new mappers to go through the tutorial. I don't > think that's the answer. It would turn too many people off. The only solution > I can suggest is to make our editing software more robust with better hints > and presets. For this I applaud iD for the many improvements that have been > made over the years. > > Best, > Clifford > -- > @osm_washington > www.snowandsnow.us > OpenStreetMap: Maps with a human touch > ___ > 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] copying numbering (ref)
Or, using unsigned_ref=* is an option. SteveA > On Feb 14, 2020, at 1:08 PM, Joseph Eisenberg > wrote: > > > “ they don't really use numbers for roads except internally” > > If they do not post signs, and locals do not usually know the numbers, then > there should not be a ref for those provincial roads in Openstreetmap. > > -Joseph Eisenberg > ___ > 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] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground
On Feb 12, 2020, at 12:28 AM, Martin Koppenhoefer
wrote:
> Start with "If A, then B" where A is "it is on the ground" and B is "you may
> map it." Now, try the contrapositive "If not B, then not A" (in logic
> notation: ¬B -> ¬A).
>
> this is not how complex situations work. "If its black it is not colored"
> does not mean that if its not colored it must be black (could be white, gray,
> etc.).
You make my point for me, Martin, and Colin reiterates it Our OTG "rule" fails
a simple logic test which should always be true ("proof by contrapositive") but
we in OSM (this mail-list, other places) say "A -> B is true, but ¬B -> ¬A (its
contrapositive) is not true!" That's broken logic about OTG, stripped to its
minimum.
It is exactly because OTG is a complex situation (breaking logic) that we must
improve OTG. If we can't state a logical rule which logically works, let's at
least start with a rule that has some exceptions we all agree upon: we map
what's OTG, but not some boundaries, mountain ranges, oceans... even though
they are neither OTG nor signed. We can improve OTG from there. Because that
is what OSM actually does.
Not to combine TOO much into one post: Frederik makes a good point that we
shouldn't blindly defer to authorities, however, when "an authoritative source"
is the ONLY thing which can provide a name (for example) in the absence of a
sign or other OTG evidence, how ELSE are we supposed to know what to tag
something? Please don't answer "ask locals" or "everybody just knows that" as
neither is a very good component of a "rule," as OTG claims to be (but isn't).
SteveA
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground
On Feb 11, 2020, at 3:45 PM, Mateusz Konieczny via talk wrote: > OTG is not "everything must be mapped on survey", it means > that direct survey (what is actually existing) overrides official data, > opinions and desires. I thank Mateusz for making (reiterating?) this important point. I believe some of us think OTG is an absolute rule which states "map what is on the ground." Logically, we should be able to "derive" the potentially equivalent statement "if you canNOT see it on-the-ground, you may NOT (should not) map it." But that's not how we map, due to numerous counter-examples (some boundaries, mountain ranges, oceans...). So, a crucial way we DO map is "if it IS on-the-ground, then THAT is what we map." The idea of "if OTG, map THAT" shouldn't be different, but is different from "if not OTG, you may NOT map this" (which isn't true, strictly speaking, due to counterexamples). I think in logical terms this might be called "a fallacy of the contrapositive." Logically, this is problematic. Start with "If A, then B" where A is "it is on the ground" and B is "you may map it." Now, try the contrapositive "If not B, then not A" (in logic notation: ¬B -> ¬A). Or, "You may not map it if it is not on the ground." Usually, "proof by contrapositive" works, as "a statement and its contrapositive are logically equivalent, in the sense that if the statement is true, then its contrapositive is true and vice versa." But in OSM, this does NOT work, because of the preponderance of examples where ¬B -> ¬A fails: in some cases we DO map it, even though it is not on the ground. And therein lies what we have to fix: proof by contrapositive fails, when it shouldn't (logically), because OSM has made and does make numerous exceptions. Let's clarify how, when and why we do this, at least as a "first cut" at how we address this contradiction. I hope that clarifies, it does help sharpen focus about OTG in my mind, simply by being stated clearly. Well, stated logically — and for some, I realize, that might NOT be clear! SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground
On Feb 11, 2020, at 2:41 PM, Mikel Maron wrote: > https://lists.openstreetmap.org/pipermail/talk/2020-February/083993.html Thank you. That's recent, and reminds me that I agreed with you as I (and I suspect others) support a yet-to-be, well-designed tagging protocol which clearly denotes these distinctions (national sovereignty vs. de facto control). This dichotomy (as in Crimea) is one more area where OTG "fails" (mm, better stated: "needs clarification"). The others (mountain ranges, oceans...) I mention in my previous (and lengthy) missives remain. This not only makes more plain OTG's problems (at its edges, mostly) but brings the topic back to the (original thread's) issue of Crimea, which isn't an edge-case, but something which OSM continues to face. While solutions don't seem easy or quickly forthcoming, I am heartened by good discussion here and in the Good Practices Talk page I linked earlier. Yes, OTG has some work to do. Again, I think we can get there. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground
Thanks, Mikel, but may I please ask what you mean by "control boundaries?" SteveA > On Feb 11, 2020, at 1:36 PM, Mikel Maron wrote: > > btw, I think it's entirely compatible to follow On the Ground, with tagging > that recognizes the distinction between political boundaries and control > boundaries. > > * Mikel Maron * +14152835207 @mikel s:mikelmaron ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground
On Feb 11, 2020, at 12:05 PM, Mark Wagner wrote:
> Have you actually been to the US-Canada border? For thousands and
> thousands of kilometers, it's really obvious:
> https://upload.wikimedia.org/wikipedia/commons/a/aa/US-Canada_border_at_Crawford_State_Park_20130629.jpg
>
> Even when it's not as obvious as in that photo, there are still
> frequent boundary cairns. And yes, they're mapped in OSM:
> https://www.openstreetmap.org/node/1997617997
I have been there, and in British Columbia, as is your example. There will
always be counter-examples to a claim of "boundaries are not always obvious or
indicated on-the-ground," (as you did, here, with a cutline in the real world
some of these being mapped in OSM). Same with mountain ranges, oceans / bodies
of water, etc. that have no signage or evidence of them (named as they are)
being OTG. Simply stated, there ARE (and always will be) things we map which
are not OTG, making OTG not a rule strictly followed.
However, we map these anyway, and by the thousand. My point is that OSM
shouldn't pretend that the OTG "rule" is absolute, as it isn't. While I think
all of us (even its original proponent in 2007, as Mikel stated earlier) agree
that OTG is "an excellent guideline to be followed where it can be," others
(Colin, Yuri) here have chimed in or infer that it can't realistically be
absolute (as it isn't, and it can't). Me, too. There seems to be consensus
that "Independent verifiability" is a crucial component of Good Practice in
those cases where OTG cannot STRICTLY be followed, as in cases of invisible
boundaries, oceans without signage, and mountain ranges where we are forced to
concede "well, everybody simply KNOWS that these are 'The Alps' or 'The Rocky
Mountains.'" The solution here is "this (and its correct name) can be
independently verified, that's "good enough for OSM" even without OTG evidence.
https://wiki.osm.org/wiki/Talk:Good_practice#Supplementing_and_clarifying_the_On_The_Ground_.22rule.22
has input from Yuri and jeisenberg and I discussing whether unsigned routes
qualify for this treatment (we can't see them OTG, but we map them anyway, as a
public agency asserts their existence, though it hasn't signed them well).
While routes like this are a relatively minor (lesser) concern about OTG,
broader discussion continues here (in talk). (I'm OK with that). But lest my
suggestion that we modify/soften OTG from a "hard rule" (which it isn't and
cannot be) into a wishy-washy, too-ill-defined "guideline," please understand
I'm stating OTG isn't a rule. Rather, it is an excellent guideline to be
followed where it can be and is, but it is a fact that it cannot be and is not
always followed. The particulars of how we better apply OTG going forward
might be difficult to describe well and reach consensus upon, but we shouldn't
let that deter us, even with disagreement.
Rather than get snarled in counter-examples, let's discuss how OTG isn't and
can't be strictly followed in many cases. It IS followed in the majority of
cases, but in those corner cases where it isn't, because it can't be ("nothing"
is OTG), must be realistically addressed, likely in our wiki where we state the
"rule" today, though going forward much better state a "guideline". I think we
can get there, but it remains under discussion / construction.
SteveA
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground
Done: https://wiki.osm.org/wiki/Talk:Good_practice#Supplementing_and_clarifying_the_On_The_Ground_.22rule.22 Follow it there, if you like. SteveA > On Feb 8, 2020, at 12:04 PM, Yuri Astrakhan wrote: > > I am in favor of this or similar language. I think for a more vote-like > discussion it might be better to use the wiki talk page (easier to add +1s > and short comments). ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground
I don't know if here or https://wiki.osm.org/wiki/Talk:Good_practice is a better place to discuss and eventually insert these suggested improvements into https://wiki.osm.org/wiki/Good_practice#Verifiability (and its first section, "Map what's on the ground"). I suggest adding these essences of this thread there: "'Independent verifiability' is a crucial component of the Good Practice of mapping what is on the ground, as sometimes there IS no evidence on-the-ground that a map feature should be appropriately tagged anything in particular. For example, some boundaries are effectively invisible, but OSM maps them (and should). Also, there are no or few signs which say "Pacific Ocean" or "Rocky Mountains," yet OSM authoritatively maps these natural=* features with an agreed-correct name=* tag. Similarly, there are routes (road, bicycle, hiking, equestrian...) which might exist on a government-published map (and hence are ODbL-compatible) yet remain unsigned (or poorly signed) in the real world. From what authority must we determine the source "verifiability" of these "invisible" or "unsigned" map features? As long as these are "independently verifiable" (by a government map, legal / statutory decree, data authoritatively published on a website, by unanimous agreement among locals and a wider public or at least with very wide consensus), the map feature with its verifiable tags may be entered into OSM following Good Practice. 'Independent verifiability' means any member of the public, freely, anytime and with no special privileges can 'consult the source' and verify the data." I'm simply tossing that out here, if it shouldn't stick, please fix it. I think it important that the phrasing is first vetted (here or on the Talk page) and I do think something like this should be entered into our Good_practice wiki to clarify OTG as we have discussed it here. Thanks in advance for any brief review and comments / suggestions you might offer, SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground
Very well stated, Colin. I agree that "independent verifiability" is at the heart of OTG and what we mean to distill from it as crucially important and a tenet of OSM that we can all agree upon (well, I hope so, anyway). By explicitly stating that John Random Public can "consult the source" (freely, in all senses) to determine "what is" even (or especially) if something is NOT on-the-ground, we actually DO largely encompass many of the exceptions of "but I can't SEE it on the ground." We may have more work to do to be more explicit, but this goes a long way: thank you! SteveA > On Feb 8, 2020, at 9:42 AM, Colin Smale wrote: > > On 2020-02-08 18:03, stevea wrote: > >> See, "the on the ground rule," to the best of my ability to determine it (an >> exception is your opinion as you explicitly express here, and that's part of >> the problem with it), isn't clearly defined and it needs the elasticity of >> such ad hoc exceptions. It doesn't say (explicitly, anywhere, except in >> your exception) "we ask people there and look at books, other maps, >> Wikipedia, travel books, organizations...if the name is used in reality." >> You do (here, as an "exception," by way of clarifying your understanding of >> OTG) but if all of that is true, OSM should say so: formally and as fully >> as possible. >> > The most important aspect of the "on the ground" rule is that things are > independently verifiable, i.e. given the evidence, anybody would come to the > same conclusion. Physical evidence is obviously very useful - for example, > either a highway is present, or it is not. But other sources, provided they > are freely accessible, can also provide facts that are sufficiently > verifiable. In the case of the US-CA border, I guess the treaty or whatever > is publicly accessible, so there can be no arguments about where the border > is in a legal sense. Of course not all boundaries are fully specified in > treaties, but I suspect this one is. > > So I suggest the "On The Ground" rule should be replaced by a requirement for > independent verifiability; our traditional definition of OTG is sufficient > but not necessary for compliance. > > Independent viability means (to me) a random member of the public, with no > special privileges, and without payment, and at any time, should be able to > "consult the source". > > ___ > 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] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground
On Feb 8, 2020, at 2:58 AM, Rory McCann wrote: > On 07.02.20 20:12, stevea wrote: >> A well-known example is (national, other) boundaries, which >> frequently do not exist "on the ground," > National borders don't exist on the ground? huh? Have you ever actually > _crossed_ an international border? I assure you they exist on the > ground. From large infrastructure, to changes in the paint colour on > roads, one can nearly always *see* where a border is. I didn't say "always" (I said "frequently," though I was being parochial / local to me). Between USA and Canada, for thousands (and thousands) of kilometers, the national border is entirely invisible. True, in places, it exists in an observable way (some stone markers, border crossings with paint-on-asphalt, even a fence or wall here or there), but I'd even say "mostly," the USA-Canada national border simply "isn't there:" nothing on-the-ground, that is. We (OSM) cannot say that "nearly always" characterizes how one can *see* where a border is. And yes, I have crossed international borders, dozens, maybe hundreds of times. By contrast (thanks for the link and photo, Minh), our wiki https://wiki.osm.org/wiki/United_States/Boundaries#National_boundary shows the stark demarcation between San Diego (California, USA) and Tijuana (Baja California, México), Having frequently crossed it, I know this boundary well and it is an example of an OBSERVABLE boundary OTG. But again, not all are. Nor are MANY things in OSM "observable OTG" like this, yet they remain in the map (and more are added each day). OSM should explicitly acknowledge this. >> Other examples include large bodies of water and mountain ranges. >> I've lived on the Pacific coast most of my life and been to dozens of >> beaches, but never once on any beach have I seen a sign which reads >> "Pacific Ocean." Same with no signs at the edge of or in the middle >> of "Rocky Mountains" or "The Alps." (I've been, and I haven't seen). >> Yet, OSM maps oceans and mountain ranges. How do we know their names >> without anything on the ground? > We ask people there. We look at books, at maps, at whether there is a > detailed Wikipedia article on the topic, do are travel books published that > refer to this area as that, do organisations that cover that area use that > term. We look to see if the name is _used in reality_. > > That's the "on the ground rule". IMO "on the ground" refers to "observable > reality". See, "the on the ground rule," to the best of my ability to determine it (an exception is your opinion as you explicitly express here, and that's part of the problem with it), isn't clearly defined and it needs the elasticity of such ad hoc exceptions. It doesn't say (explicitly, anywhere, except in your exception) "we ask people there and look at books, other maps, Wikipedia, travel books, organizations...if the name is used in reality." You do (here, as an "exception," by way of clarifying your understanding of OTG) but if all of that is true, OSM should say so: formally and as fully as possible. Such fuzzy semantics land us where we are: in ambiguity. Let us acknowledge that such exceptions (and there are many of them) exist and best deserve to be explicitly described. We should do so for the betterment of the rule. And, "rule" becomes "good guideline, applicable where it can be easily and unambiguously applied, but with sensible exceptions we can largely but probably not exhaustively delineate." With such dialog, we get closer, yes. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Crimea situation - on the ground
Without touching the Crimea specifically, I'd like to chime in that "on-the-ground" (OTG) is a good rule, but in reality it must be approached more like a goal to be achieved where it can be, as we must acknowledge that realistically, this rule both cannot be and is not applied everywhere under all circumstances. That is the simple truth and OSM should not pretend otherwise. Maybe we need to tighten up our language about how we define OTG to better acknowledge this, clearly and explicitly. A well-known example is (national, other) boundaries, which frequently do not exist "on the ground," but our map data would be remiss if it excluded these. So we do our best to include boundaries even as they are not on-the-ground, but exist in both de pure and de facto ways in the real world, so OSM expresses them. Yes, when boundaries are disputed, this is difficult: there is no way around that and it isn't unique to OSM. I like Mikel's recent suggestion positing that OSM can better develop tagging that accommodates a wide array of disputes, as we do have plastic tagging and it can evolve well. Other examples include large bodies of water and mountain ranges. I've lived on the Pacific coast most of my life and been to dozens of beaches, but never once on any beach have I seen a sign which reads "Pacific Ocean." Same with no signs at the edge of or in the middle of "Rocky Mountains" or "The Alps." (I've been, and I haven't seen). Yet, OSM maps oceans and mountain ranges. How do we know their names without anything on the ground? It's a tricky question which usually starts with some hand-waving (especially for enormous, major-chunk-of-planet-sized entities like oceans), and progresses to "well, everybody simply KNOWS that's the Pacific Ocean..." and we are faced with OTG and an inherent contradiction of what we should do, then we do it anyway. (Name something without having a solid OTG reality). To a lesser (weaker) extent, OTG flexibility might also apply to newly developed routes (bicycle routes are a good example) as these may not be signed (or well signed), yet a government (whether local, state or national) expresses these as real (on a public map — just as with a boundary) and poorly signs or doesn't sign them at all in the real world. OSM uses "unsigned_ref" to denote these, but it's a fuzzy semantic that doesn't have wide agreement or even consensus. I have seen the opinion that these shouldn't be in OSM at all, which seems a shame for things which many local users (of a bike route decreed by a government, for example) agree do "exist," yet there isn't any OTG evidence for this. While one tenet of OSM is "don't copy from other maps," when the only evidence that something exists is ONLY from a PUBLIC map (yielding us ODbL permission), we have to reconcile that with OTG. Today, we don't do that very well. So, rather than being fully enthusiastic about the absolute application of OTG (we simply can't), let's realize that it is a good guideline which should be followed where it can, yet it must include some flexibility which allows for exceptions. I haven't seen that said (here, yet, perhaps it is elsewhere) and I believe it is important to be explicit about it. SteveA California ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects
On Jan 16, 2020, at 3:24 PM, Tomek wrote: > La angla lingvo estas plago de la nuntempa mondo (The English language is a plague / scourge of the contemporary world). While I strive to accommodate (and often do) and I resonate well with Frederik's pleas to be pragmatic, avoid zealotry and "the usual language on this list is English," I can't help but find highly offensive calling my native language "plague de la nuntempa mondo." (Ironic is that I speak some Polish and Esperanto as well, but find them to be inappropriate languages here). I will say that phrase one more time: "highly offensive." Tomek, of course I see your point(s), but as my mother says, "you catch more flies with honey than you do with vinegar." Please stop offending this list's readers with your opinions, especially as they contain insults to their language — that is wholly uncalled for. I sometimes say to people, "thank you for your opinions." With you, here and now, I do not. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Too subjective & problematic Re: no-go-areas
I agree. In the USA, the five-digit postal code was introduced in 1963 and
called a "ZIP code," for "Zone" (first digit), "Improvement" (second and third
digits), "Plan" (fourth and fifth digits). In 1983, nine-digit codes were
introduced by adding a hyphen after the five digits and four more digits
("Sector" sixth and seventh digits and "Segment" eighth and ninth digits),
hence the newer designation "ZIP+4." More recently, the Coding Accuracy
Support System (CASS) systems added two more digits to standardize the exact
"delivery point" (where 10th and 11th digits are calculated by CASS software
based on the number in the address) and a final, 12th digit as a checksum.
Helpful to remember about ZIP codes (proposed since 1978) is that they are NOT
geographic areas (as can be mapped in a map), but rather "routing algorithms"
helpful to facilitate mail delivery.
I believe it is widespread consensus in OSM that while there are places where
adding boundary=census polygons is considered helpful data (especially in
Alaska's Unorganized Borough, as they are a joint effort by both the US
Department of Commerce's Census Bureau AND the state of Alaska and have become
a de facto, though not necessarily de jure definition of administrative areas),
usually, adding census data to OSM is not especially helpful. But there are
much of these extant now.
I also believe it is widespread consensus that OSM should not contain postal
(ZIP) code data in the USA, as ZIP codes (strictly speaking) cannot always (or
even usually?) be defined as geographic areas, they are rather better thought
of as a "routing algorithm to help facilitate mail delivery."
SteveA
California
> On Jan 13, 2020, at 4:34 PM, Joseph Eisenberg
> wrote:
>
> In the USA a postal code is not actually an area, but a set of
> addresses. Often they are all in one area, but sometimes the area is
> not clearly defined. This is partially why postal codes are usually
> just added to the POI directly in the USA. Trying to make a sensible
> set of areas or boundaries will not work for all USPS postal codes.
>
> Joseph Eisenberg
>
> ___
> 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] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects
> Se vi parolas Esperanton, kial vi ĝin ne uzas? Because this is an English-language list. > Kial mi devas uzi > elektronikan tradukilon por kompreni vian mesaĝon, kaj vi postulas por > skribi en via gepatra lingvo? Mi ne devigas al aliaj homoj lerni mian > lingvon (la polan). Kiu estas fanatikulo tie ĉi? I speak some Polish, too. Yet, I don't wish to fight with you. I will continue to use English here, though I will not continue to answer you when you write to the list in Esperanto (or Polish). Why? I repeat myself (as do others here): because this is an English-language list. Peace, SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects
On Jan 11, 2020, at 2:12 PM, Tomek wrote:
> EN
> English fanatics, please read the text:
> http://sylvanzaft.org/verkaro/Esperanto-A_Language_for_a_Global_Village.pdf
No thank you. I am not a "fanatic" of my mother tongue, I simply use it along
with hundreds of millions or billions of others — um, not all of them HERE, of
course, but there are enough English speakers here, and there have been since
Day 1, to make it an interesting and informative place to have conversations
like this. Not to mention I am multilingual (though my Esperanto is
35-year-old-rusty).
What I would much rather do is continue discussion on this list in English, as
we always have. It is good discussion, but I don't appreciate being
name-called ("fanatic") or told to "go learn a new language." I mentioned that
I was a founding member of my university's Esperanto Club, so I know the
reasoning behind why people might want to learn the language. But I don't
believe it was ever meant to be rammed down anybody's throat. (Which is what
that felt like).
Opinions are mine.
Thanks for your understanding and peace to you,
SteveA
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Too subjective & problematic Re: no-go-areas
> On Jan 11, 2020, at 12:22 PM, Martin Trautmann via talk > > and > On 20-01-02 12:23, pangoSE wrote what they wrote. To be clear, the hazards I'm hazily identifying are naturally-occurring or are human-made real-life hazards that can cause you real harm if you approach them and are not careful to avoid them, not "stay out of that neighborhood" kinds of "hazards." Things like an area which is radioactive, has a "falling hazard" (such as a pit, though I think we have "adit" for mine shafts — and we do have natural=cliff, which I agree suffices for what it is) and other unusual hazards like places which have a propensity to be repeatedly struck by lightning (that's a weird one, and kind of controversial, I know). As before, I doubt "hazard" or "no-go" will get more traction than it has (here and now), I simply make that clarification. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] Tagging the local language
That is an outstanding way to say a whole bunch of good stuff all at once. +1 is an understatement. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] Tagging the local language
On Jan 10, 2020, at 7:06 AM, Martin Constantino–Bodin wrote: > I fully agree. I was only taking the example of South America because its > language community is relatively simple given the size of its area ☺ But I > agree that it’s probably not something that we should actually map. Sorry > about that: it wasn’t clear in my message. I don't usually post here to "throw rocks," but I must say that the language communities in South America are QUITE diverse — anything but "relatively simple." In addition to the five European languages of Portuguese (#1), Spanish, English, French and Dutch, there are dozens of indigenous languages (Quechua, with about 9 million speakers, Guarani, Aymara, another 7 or 8 million there...) that span the continent. Additionally, significant numbers are found of speakers of Italian, German, Arabic, Welsh, Coratian, Greek, Polish, Ukrainian, Russian, Romani and some clusters of Japanese, Hindustani, Javanese and Rapa Nui and Maori on Easter Island. Just saying. This is not an easy situation. The United Nations has "six official languages," that's not ideal, either. Absolutely anything OSM does will be a compromise, but I agree that we should strive for the most appropriate access to a culturally-appropriate solution. Great results seldom come from anything less than serious effort. I encourage continuing work on this important continuing development of OSM. Good dialog here is certainly part of that. SteveA California ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] no-go-areas
On Jan 5, 2020, at 9:48 PM, Julien djakk wrote: > Hello ! For this kind of tagging, which is as subjective as the > highway=secondary, there should be a consensus of local mappers. > > This kind of areas could be tagged as “you need to know the area to be safe > among locals” :-) I listen to this as potentially reasonable, but I am left with the (obvious?) question: what, exactly, is the specific hazard? Is it characterizable, identifiable? Is there a formal border around it? Does everybody agree? All of those seem difficult "to be (true) simultaneously" (as I understand what is meant when somebody suggests "avoid that area because of, or unless..."), so I fall on the side of "if no identifiable hazard, then no specific tag." In short, I think we agree: too subjective. Even WITH a consensus of local mappers, I don't believe it stands tall enough unless it rises to "true" for all three of those questions. And likely some more I haven't typed here, too. (Others might). Specific hazards, that are characterizable, identifiable, confined to a well-defined area and widely agreed upon? Yes, Earth likely has some of those. A node tagged hazard=* might work well. This feels like a rough sketch only (still) despite getting shot down repeatedly as an unfocused or wholly wrong idea. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects
We shouldn't abandon English "because it is 2020." I feel strongly about that. Many do. We are here. Some of us speak English. Here, we do (that). (Speak English). It is what is done here. It is what we do here. This is not shocking to anybody. If you wish to have some feedback of your Polish and Esperanto (here, now), OK: meh. Please, continue to use English here. Any dialect. Polish and Esperanto (also), as you have, OK, (I tolerate it), but you have always included English, so "OK." You didn't include EN. Not OK. Not here. Thank you for your future cooperation. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects
Whoops, "I can read PO and EO, too" is what I meant to type. See, it's this "let's not get snarled up in differing languages thing." We can do this, we have. It's easy to goof things up and we shouldn't. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects
There is an EN idiom: "give him an inch, he'll take a mile." Tomek, the list (our OSM project...) gave you inches and you took a mile, as you exclude EN from here. Just saying it out loud so you understand that there are billions of English speakers. Some of us here. Sure, I can read PO and EN, too. Poorly. And I suppose, luckily for you. Please abide that English, simply, ain't, isn't going away here. I speak it, billions of us do. We are here to make a map, largely agreeing with each other as we do. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects
My grandfather was born in Poland and I grew up hearing and speaking Polish, and I was a founding member of the University of California, Santa Cruz' Esperanto Club (a long time ago). But, as others have said, (and English is my native language), this IS an English-language "channel." May we please see posts in English (any dialect) here, please? That is, if you wish them (widely) read, here. SteveA California ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] no-go-areas
Right, Martin; thanks. Joseph and I discussed off-list there is some conflation of tags from hazard=* which intersect well with at least one or two existing military=* tag values. So, yes, there is some overlap with existing tag (natural=cliff, too). I have read our hazard wiki (thanks for the ref) and also mentioned to Joseph that hazard=* seems (in addition to being 12 years old and ripe for an update) a bit too much "car and driver" oriented. For example, if a sign warns of "moose crossing" or "children often play near this roadway here" OK, put that sign on a node onto or next to the highway. In addition to chasm going away, radioactive hazards (there's ionizing radiation, RF energy...) and that there are even places where you wouldn't want to be standing during a thunderstorm as they are struck by lightning repeatedly (yes, really: seems there might be one or two in Texas and Canada) there are really verifiable "hazard=yes" places (that are not subjective and quite verifiable) where a node and a brief mention might be a real thing we could very well want to add to our map. Nudge forward, I don't have massive passion or energy to go much further with it, next up, please! (Yeah). What a great project, OSM. (I truly mean that). SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] no-go-areas
I've certainly tagged plenty of natural=cliff (and I'm not done yet), there's lots of them around me. So perhaps hazard=chasm could deprecate as one value of the proposed key hazard, deferring to natural=cliff. Still, there are plenty of objective, not-going-away-soon, not-politically-sensitive hazards on Earth. We should map and render them, but to do so, we might resurrect a more-modern version of the hazard tag proposal. Or anything else that would do the job. These do seem like good, smart things to map. Good dialog, thank you everybody. SteveA > On Dec 31, 2019, at 10:59 AM, Mateusz Konieczny > wrote: > > 31 Dec 2019, 19:35 by stevea...@softworkers.com: > Really? Actual, real-life hazards like [chasm > natural=cliff? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] no-go-areas
Really? Actual, real-life hazards like [chasm, radiation, rock_slide, minefield...] are not worthy of that tag on a node and some Carto-code to toss up a triangle-! icon on our map? Where's the harm? (Literally). Perhaps we implement these without including (or specifically EXcluding) the more "sensitive" ones which are considered "subjective." We can't be "too subjective" if we aren't subjective at all. But, explicitly objective hazards do seem worthy to map. Many (most?) like radiation, live minefields, military bombing areas, sharp bluffs / cliffs are not transient at all and would likely remain as long-term hazards. I think we should revisit this rather than dismiss it matter-of-factly as "oh, that hazard thing that pops its head up every year or so." SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] no-go-areas
As a long-time OSMer, I offer perspective on two "dangerous areas" near me, one past, one present. On my university campus (University of California) there WAS an area in a meadow which was grazed by cattle (both from the original landuse from a century ago and presently, as these meadows are grazed by cattle even today, at a university of tens of thousands of students). A decade and longer ago, there was a swale (low-lying area) which I believe was human-converted into a sort of reservoir for watering cattle, but it had steep sides, was quite deep and could be impossible for humans or cattle to escape if they fell into it, especially when empty / dry. Not by me, but this was marked on OSM as a "no go area," which I always found curious, as that wasn't an explicitly defined tag. I'm nearly certain that today, this dangerous area has been "remedied" (filled in with dirt) and no longer exists as a hazard on campus. In OSM, there is no longer anything (node, way) in the area to tag as such; it has effectively disappeared from both the real world and our map. Also near me is a "beach" (it sort of is, sort of isn't) which is a dangerous place to ocean-swim, it is known locally as the "Toilet Bowl" as it has nasty churning surf and undertow currents which I believe have drowned at least one person. When I heard local news that such a drowning occurred yet again, I endeavored to tag a node there with name=Toilet Bowl (dangerous area, no swimming) + swimming=no + hazard=yes. (Yes, I know that violates "name is name only"). Also, there isn't a "physical" tag (like natural=beach, as that is unusual, though not wholly wrong, on a node). Yet I couldn't help but feel that hazard=yes, a "draft / underway proposal" (since 2007?! really?) is insufficient: the value "yes" isn't documented in the proposal, and others listed there, like chasm, radiation, rock_slide, minefield, playing_children... didn't fit a dangerous swimming area. Plus, the hazard tag doesn't render (a triangle with exclamation point might be a good starting icon). I believe OSM needs better, explicit tagging to identify dangerous, hazardous areas, and Carto should render these. There are many different kinds of these, from those I just noted, to "high-crime area" and what others might consider sensitive or political. (We shouldn't be afraid to say that an explicit hazard exists if one does). A proposal that seems to have gotten stuck for 12 years seems it's a good starting point, can it be resurrected? OSM mapping these would be another welcome feature in our map, as I know of no other general-purpose map (that IS how many use OSM) which identifies these sorts of "everyday" hazards. Think about it: a hazardous situation might find YOU one day, and you might be very glad you saw this on a map beforehand so you could avoid it. SteveA California ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is OSM a fake map.
OSM is not a "fake map." OSM is a crowdsourced map, pretty good in many places, even excellent in others. Does it have errors? Yes, as do all maps. Do these errors diminish and does the map improve over time? For the most part, yes, unlike many maps. If you don't like OSM or find it doesn't suit your purposes, you do have the option of not using it. If you find errors in the map and you are able to correct them, the people in this project certainly appreciate that, so please feel free to do so if you find yourself so inclined. If you wish to criticize the map without being constructive about it, you may not find many helpful or sympathetic people here, as unconstructive criticism is not especially helpful. It is not the case that "all mappers are tracing." Some do, yes, but others "walk, bike, ride a train, trace-via-GPS" and enter these data into OSM, certainly in places where there is tree cover that prevents aerial / satellite imagery from displaying what is underneath it that might be interesting and correct to map. This enters "better" data (than tracing something which may be wrong, or when tree cover frustrates that kind of source data from yielding any helpful data to enter). So, I'm at least one person who DOES say that OSM isn't a fake map, and those are only some of the reasons why. There are plenty of other reasons and plenty of other people who agree with me. SteveA California ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] water runs backwards.
To be clear, it isn't necessarily from "bottom to top," rather, simply know and practice that the direction of a way tagged waterway should be in the direction of the water's flow. I continue to clean these up, even locally to me and hiding under my nose for ten years. They are easy to miss, simply fix as you see them, please. SteveA > On Dec 22, 2019, at 6:00 PM, 80hnhtv4agou--- via talk > wrote: > coming across bad mapping, if you draw a water feature ditch, or stream, from > the bottom of the map > up, you get arrows showing the flow going the wrong way and there is no way > to fix it like a one way road, > and we are talking about miles long segments. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Osmf-talk] Attribution guideline status update
I respect that, for as far as it goes. This particular issue is specifically called "no code" and for that simple reason alone does not resonate well in many minds as "good intersection with GitHub." Besides, who says a contract (license) with GitHub intersects well with OSM and its open-data / open-tools philosophy, again? You? For this case? Masses of the silent? I hear your preference, I doubt it is "masses" either way. There might be significant numbers, though there are significant numbers of wiki authors and contributors and have been for the entirety of OSM. Wiki is not only a well-established channel, it may be one of the better or even best ones. GitHub? Mmmm, no, and while it does have its place, it is not as a direct substitution for any particular notification or documentation system (these are different, true). As for the wiki "isn't the easiest" OK, thank you for your opinion, but I continue to call it "easy." Very low bar of entry (especially as one is already an OSM volunteer), unlike GitHub which requires a separate contract (essentially, of adhesion). I don't have a secret-sauce walkie-talkie like you do (and you won't have all of mine, is the point), but we all have wiki access built into OSM. You might be tempted to say "OK, Boomer" and I'd be rightly miffed, but I'd prefer to reduce rancor and simply observe, yet again, "yes, both." Only, not a lot of people naturally gravitate to a "non code issue" as GitHub as their first go-to, the contradictory nature of that seems clear to me and many. The wiki, maybe yes, maybe no, (there is wiki, there are others) but yes should neither surprise nor annoy, nor does it. SteveA > On Dec 22, 2019, at 3:43 PM, Mario Frasca wrote: > one voice from the silent mass: I prefer github for such issues. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Osmf-talk] Attribution guideline status update
I wouldn't be so quick to dis our wiki, Guillaume. Personally, I find it a relatively-easy-entry system for plastic, live documentation of a project and its data, process and people. It serves this purpose well even for less-than-tech-friendly folk and has for the life of our project. Wikis can be encyclopedic in their scope, yes. However, building long-term (many years) projects out of them is a proven-many-times case. Wikis accommodate fast-moving and slow and steady growth alike. Color-coded tables often provide at-a-glance status. It isn't hard to copy-and-paste and build things out of things, with other people building things, too, meet-ya-in-the-wiki. SteveA California ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Osmf-talk] Attribution guideline status update
I believe Nuno HAS "reacted positively" by his frequent and constructive criticism of what he has seen taking place by third parties who use OSM data without proper attribution. I'd have to check, but it seems he has been doing this for the better part of a year (maybe longer). While I don't wish to diminish the light-hearted, holiday-spirited suggestion Pierre makes, I can't help but feel it detracts from the seriousness of the concerns expressed by Nuno. I don't think that was Pierre's intent, but it could be easy to misinterpret his comments that way. SteveA California ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?
I don't know. I've expressed my opinion(s) on the matter, and believe the LWG should chime in with "an" (the?) answer. SteveA California > On Nov 14, 2019, at 3:27 PM, Martin Koppenhoefer > wrote: > sent from a phone > >> On 15. Nov 2019, at 00:19, stevea wrote: >> >> But the "ultimate test" of "can the new work be made without OSM data?" >> remains a good one, in my opinion, because then, the author can be told, >> "well, then, go do so, please, otherwise offer us attribution of some sort" >> (whether legally required, or not). > > > if you distribute a dataset and say: all roads but not those in > OpenStreetMap, isn’t this already attribution? The question is whether you’d > want to force them to distribute under ODbL rather than MIT (and maybe what > the downstream users have to attribute). > > Cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?
Yuri, I appreciate your analogies and making the point about "derived." Yes, we are inspired by architecture we see, if we incorporate a little finial from a public building in our new roof project, do we owe the architecture money, or a nod? There are plenty of examples like this in real life, we all "stand on each other's shoulders" to some extent in everything we do, whether it is a language / culture we share, or identifiable elements that somebody might point to and say "well, clearly, here is a case of 'imitation is the sincerest form of flattery,' as clearly you were inspired by another work." That happens, I realize, it is part of the human endeavor. I'm making the point (especially as I say "inspiration") that if OSM data "inspire" the new work, it might be derived. It is certainly "inspired," but it might not legally be derived. Once again, I don't know where to draw the legal line, but I do have an opinion that if new works cannot be made without OSM, some attribution should be made to OSM. Maybe legally yes, attribution is required, maybe legally, no, it isn't. But the "ultimate test" of "can the new work be made without OSM data?" remains a good one, in my opinion, because then, the author can be told, "well, then, go do so, please, otherwise offer us attribution of some sort" (whether legally required, or not). These are ultimately questions for the Legal Working Group, however, I do hope they are inspired by the strong feelings and opinions of OSM volunteers about our data / works. SteveA California > On Nov 14, 2019, at 3:09 PM, Yuri Astrakhan wrote: > > stevea, I would not be exactly the same person without OSM. Does it mean ODbL > applies to me? A hammer was used to build a house, but the house does not > have hammer's copyright. Just because some data was used in the process does > not necessarily mean that whoever saw that data taints everything they touch > from thereon with ODbL license. In some cases it does, like when portions of > OSM data make it into the final product, but I seriously doubt that if > someone computes average time OSM editors contribute to the OSM project, and > publishes that average, and afterwards someone else publishes how often > someone publishes papers about OSM community, they must use ODbL license... > Even though that last research paper would not be possible without the first > research paper, which would not be possible without OSM data. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?
While exactly "the data" may not be "in" the derived work, because of the process of their creation, "their spirit" are in the derived work, as they were a part of the new data's production. That strongly seems "derived" to me, whether that "spirit" is inspirational or gives rise to "do include this, don't include that." These decisions are based upon OSM data, so OSM is being "derived" to make the new work. Again, if the data aren't derived from OSM, please create them exactly the same withOUT OSM data and "then we shall see" (whether OSM data are necessary or optional for the new work's duplicate creation). If you can do that without OSM data, please do so. If you MUST use OSM data (even if no actual OSM data end up in the final work), then please agree that the final work is at least partly derived from OSM data. This doesn't seem that difficult to do on a verbal level, though again, I'm not sure of how it holds up legally. SteveA California > On Nov 14, 2019, at 2:45 PM, Martin Koppenhoefer > wrote: > I guess the law often doesn’t work like common sense. ODbL says it protects > the database or a substantial extract of it. Where’s the data from OSM in > this dataset? > > Cheers Martin >> On 14. Nov 2019, at 23:25, stevea wrote: >> >> But if you DO use that "OSM over-layer," then please: agree with common >> sense that those work are derived from OSM, even if they do not contain OSM >> data in them. They contain data "helped" by OSM data, so they are derived >> (I would argue). ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?
I'm not an attorney, but I do have an opinion. Just because there "is no data from OSM in the dataset" does not mean they are (or aren't) derived. If OSM data were used in conjunction with its production, I think an argument can be made that those work are derived. The question would be: "can these data be created exactly as they are WITHOUT any OSM data (used as an over-layer, for example)?" If so, OK, then "don't do that" and create them that way and there isn't any question. But if you DO use that "OSM over-layer," then please: agree with common sense that those work are derived from OSM, even if they do not contain OSM data in them. They contain data "helped" by OSM data, so they are derived (I would argue). SteveA California > On Nov 14, 2019, at 2:19 PM, Martin Koppenhoefer > wrote: > > I would believe it isn’t a derived work, as there is no data from > OpenStreetMap in the dataset. > > I agree with Mateusz, if they trained their ai with OpenStreetMap data, you > could take the position that every outcome of their blackbox is > OpenStreetMap-derived, but AFAIK it is a gray area. > > > Ciao Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Addressing SIG
Nicely answered, I appreciate that! SteveA > On Nov 8, 2019, at 4:02 PM, Martin Koppenhoefer > wrote: > > > > sent from a phone > >> On 9. Nov 2019, at 00:48, stevea wrote: >> >> I wouldn't say "all" addresses, as Facebook isn't "all" of us. > > > of course, I apologize if this came along like a campaign just with facebook, > it was just an example that facebook was mentioned, because they are our > biggest data user (Apple as well, but they don’t use OpenStreetMap data in > their most important markets, AFAIK). Collecting _all_ addresses is a > project goal (it’s part of mapping the whole world), and was not referring > specifically to facebook, nor had I imagined a campaign just with facebook > (if they are interested in this anyway), making such an announcement could be > an occasion for the media in general for featuring OpenStreetMap. The people > vs. Big Tech etc. > > Cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Addressing SIG
I wouldn't say "all" addresses, as Facebook isn't "all" of us. Also, it's an ambition, a gleam in a collective eye, a vision, something ahead in the future as a goal. There will be, rightly, many paths to get there, rather than a single one. This is true of any major goal in OSM. SteveA > On Nov 8, 2019, at 3:44 PM, Martin Koppenhoefer > wrote: > We could announce a campaign, “citizen mapping project collects all the > addresses in the world and provides them freely to everybody” or similar. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging Governance
ject like OSM, in my opinion). No, it is as Roland says, "More Structure needed." I don't know where the sweet spot between "free form" and "More Structured" is, but we're on a path where we are devolving into "too little structure" and it seems to be hurting us. How do we BUILD that structure? That's a good question! I don't know what to do about all this. I simply agree that a wider discussion of "how" (do we better communicate, bring together many disparate channels of communication, do we get people to either read our wiki, write into the wiki when it's a good idea to do so, or both) is long overdue. Roland seems to be leaning towards using "more modern" methods like how Git uses "better-evolved" software development (documentation development, data-entry / data-improvement-over-time development...) methodologies to "get things done better." Yes, I wish it were as "hand wavy easy" as that, like we could simply wish that things were better, or adopt some ready-made technological solution that some company perfected and then tossed into the public domain. However, if we don't talk about "how," first identifying problems, then proposing solutions and perhaps even achieving some of them, we'll never, ever get there. I wish I had done a better job of articulating the feelings I have had for many years of mapping in OSM about this (there are many problems), but hopefully talking about it will continue dialog that might move things forward. Unfortunately, I have experienced more of the "bad mood" that Roland mentions far more frequently in this great project in the last year or three. I'd love for us to figure out how we reverse that trend. Perhaps we "home grow" this by starting at the "grass roots" level of specifying how we might better do this and grow it up ourselves, developing it similar to how commercial companies do so. There's a lot of experience in OSM of "open projects," including open data projects, let's leverage that knowledge. But ours should be "all OSM, built right here in OSM." We already do that to a large degree, but because of that (recent, it's true) "bad mood," it seems we must do more. Please, let us do more. We can start with "tagging governance," the subject of this, and while it feels like a lot to bite off and chew, it also doesn't feel like too much. SteveA California ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Osmf-talk] Attribution guideline status update
I don't want to sound overly simplistic, but as a copyright holder, I believe if ANY amount of my (or "our" in the sense of copyright shared among many individuals, as are the rights in OSM's ODbL) data-under-license are included in a derivative work, and I mean ANY non-zero amount, "attribution" (as ODbL defines attribution) is legally required. I believe ODbL agrees with this (there is no mention of "percentages" there), though I am not an attorney. Why is this so difficult? "Any non-zero amount of OSM data yields a legal requirement for proper attribution." Do I miss something? SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] sending location from a smart phone.
This feels like an interesting side project for OSM to keep its hands warm, rubbing over the campfire, ready to toss in a shoulder of help if needed. Warin (below) says "a few years" yet I think with some good communication, coordination among countries, 112 / E911 / 999 communities, mutual aid / volunteer fire departments, writers / coders of iOS and Android apps, this could really turn into something reasonably effective in a year or less. A 1.0 that works worldwide and is extensible to any country (depending on phone / cellular / G3-G4-G5 tech, whether the call center can handle SMS, whether the helicopter pilot and rescue team have data delivery systems that show them a map or visually / aurally read a string of lat-lon digits — not helpful, a visual map is usually immediately human-parsable) seems quite feasible to me. By 2020. Nice discussion. Thank you for introducing the topic, John. May it continue and blossom. SteveA > On Aug 17, 2019, at 8:19 PM, Warin <61sundow...@gmail.com> wrote: > > On the SMS front, it is not a question of an app but the receiving > organisation > > Internationally 112 is the single number that is allocated to emergency > services from cell phones. > In some countries that gets you a call centre that then sends you off to the > police, fire or ambulance. in other countries you may end up with only the > police. > > Having them all contactable by SMS would be nice... but I don't think it is > going to work world wide for many years. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] sending location from a smart phone.
As I think about it, there's likely E911 (in the USA) organizations (standards bodies, coordinating mutual aid people...) who either are talking about this or already have. I imagine an app which is smart enough to "burst off to all possible channels of communication, whatever your emergency response network is able to absorb" (text, voice, GPS text SMS of decimal lat-lon...) because this is an app I downloaded in case I needed to send my location to emergency rescue-type agencies via this smart phone, and I'm clicking on the app (and confirming to "send my location to emergency authorities?" now). Such apps usually revise and get smarter and more coordinated / localizable / extensible / smarter as time goes on, anyway. Again, this doesn't seem too difficult to get coordinated and build an app and develop the syntax and functionality so it is localizable and flexible enough to "do the right thing(s) in context" (of whatever country or G3, G4, G5, 911, 999, whatever..) tech / country / system / network / whatever. Not a no-brainer, but it seems like if humanity doesn't have this app (and people downloading / installing it by 2020), we might be lagging a little bit. Let's sew up the loose edges here and maybe OSM discussing amongst ourselves on talk turns into (by 2021) stories of "we saved the lost family in the desert...", too. It's not farfetched. Really, a lot of good ideas and "W3W inspires OSM to standardize a 'plain vanilla' version of this" (and maybe OSM has something to do with a sort of "generic, install on your phone as a good idea," maybe not) here. SteveA ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] sending location from a smart phone.
John's on the path here: let's eliminate a potential cut-and-paste (or remember "too many digits" step). If there isn't an app (Android, iOS...) for "tap this button to ask the GPS to put my lat-lon into a (decimal) text string and prompt me for the phone # of an SMS that sends it (with my return phone #, of course)" there should be. It wouldn't be terribly difficult or lengthy to write, imo. Lat-lon (decimal emerges as unambiguous) continues to be "we all have the (open) tech to know exactly where this is" depending on how many decimal points of precision. (W3W? Seems like BBC shilling for that particular proprietary method, there are any number of such coordinates system out there). Anybody know examples of such an app that goes straight from GPS lat-lon text to SMS? > On Aug 17, 2019, at 6:22 PM, John Whelan wrote: > > Apparently some Fire brigades ask people who are lost on moors etc to > download What3words then tell them their location. > > Isn't there a simpler way? Perhaps to get a text message sent with the long > and lat? > > ref > https://www.bbc.com/news/uk-england-49319760 > > > Thanks John > > > -- > Sent from Postbox > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
