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

[Yuri Astrakhan]

Rory, I agree with you - there are always corner cases.  And while we
concentrate on the geographical aspect (e.g.  "somewhere there might be a
large territory where the tags mean different thing"), the corner case can
actually exist in our own neighborhood, simply because our neighbor
understood some tags to mean something different.

To use the a handball vs team_handball example - if it wasn't for you, no
one would have been aware of such a distinction, and if we had a @talk
discussion of the global bot autorename to fix it, there is a good chance
it __might__ have been overlooked, and damage would be done - we don't have
as many people monitoring @talk, as we have actually mapping things.  But
if someone made a challenge to convert handball->team_handball, someone
would have caught it in your area, thus flagging the issue globally,
documenting the distinction, and cleaning up the other areas where having a
mix of both values is incorrect.

On Tue, Oct 17, 2017 at 8:29 AM, Rory McCann  wrote:

> On 16/10/17 19:49, Tobias Zwick wrote:
>
>> Except that's not true. In Ireland "handball" is Gaelic Handball¹
>>> which is a one-on-one game, not a team sport (which is apparently a
>>> different thing²). There are some sport=handball's tagged in Ireland.
>>> Now the tag is clearly wrong, and we need to figure out something about
>>> that. But if you just change sport=handball to sport=team_handball, then
>>> you've entered incorrect data, based on incorrect assumptions.
>>>
>>
>> Good catch. So, it is no good as an example for that. But no matter, I
>> think the idea got across anyhow.
>>
>
> The idea that automated edits and tag replacements on a worldwide scale
> are a bad idea and might have edge cases you've never heard about? 
>
> but it is the only documentation we have.
>>
>
> Not really. We have editors, and what they do, map styles and what they
> do, programmes like osm2pgsql and what they do. That's a form of
> "unwritten documentation".
>
>
>
> ___
> 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] Could we just pause any wikidata edits for a month or two?

[Yuri Astrakhan]

Lester, I agree with you that Wikidata should not contain an object for
everything that OSM may have.  I don't believe there should be an entry for
every McDonalds on the planet, or for every artist's work that someone may
decide to include in OSM.  But that's up to Wikidata contributors.  Lets
instead talk about practical usages of our data.

Here is a wonderful site I saw at a conference a few days ago.  It lets you
plan your trip based on the places you are interested in.  You can
visualise all sorts of places - cultural, religious, hotels, bars -
anything, and plot your course.  And it uses Wikidata, images from Commons,
and Wikipedia text itself to describe the places.  The authors spoke at
length how Wikidata tags in OSM has helped them build it, and the
difficulty they had in all sorts of "data voodoo" to figure things out.
For example, they often correlate OSM & Wikidata locations by proximity,
and try to guess if it's a match. They have done an outstanding job making
sense of our data, but I think we could have made their job a lot easier
with our communal data curation capabilities, and also help others who may
have similar needs.

https://opentripmap.com/en/#14/40.7355/-73.9806

You do raise an important point about 1:1 vs part of vs ...  In order to be
useful in data processing by 3rd party, data needs to answer a simple
questions:  does the linked Wikidata/Wikipedia represents this whole
object, or is it simply related to it in some way.  Here, the 1:1 is meant
somewhat loosely - there are some cases when things don't align perfectly,
but that's a separate topic.

If wiki* page is about that object, the consumer may choose to use
multilingual names, show a portion of Wikipedia articles in the user's
language, use Wikidata statements, and show images from Commons.

If wiki* is only *related* somehow to the object, no such automatic usage
is possible. The link is still very valuable for the editors of the map,
but not as much to the data consumers.  Examples include a wiki article
that has just a section about this work of art, or wiki page is a list that
includes all churches in the area, or describe a class of these objects
(e.g. brand) but not this object itself.  Moreover, I suspect our favorite
tools like Nominatim would also be mislead if they rely on Wiki* links that
relate to the object, but not about the object itself. After all, if the
object is well known, it would probably have its own wiki page, or at least
a wikidata entry.

Some translations are completely different articles?

I'm not sure what you meant here. I have heard of rare cases when unrelated
wikipedia articles are connected to each other, but usually those get fixed
as soon as someone notices.


> The problem I still see is that many of the items I am looking to link to
> are elements of an article rather than the whole article, such as the
> location of the works of a particular artist. At some point in the
> future wikidata may well have a complete index of QID's for every
> artist's work, but currently I don't have the time to add wikidata
> entries where they don't exist, so a link to the artists wikipedia
> article which may or may not actually list this particular work is
> second best and in many cases there is not even an english version :(
>

Sure, lets just add it as a different tag, not wikipedia/wikidata. We could
call it related:wikidata or related:wikipedia:en, or subdivide it even
further. Note that here, unlike the main wikipedia tag, the
related:wikipedia:en might not be the same as wikidata. Moreover, I would
argue that here we should use related:wikipedia:xx format with the language
code, because the article content is likely to differ between languages.


> Some bot then modifying that link out of context is not helpful and
> while the idea of 'nobot' flags may seem a solution, it's just adding
> another layer of complexity which potentially needs to exist for EVERY
> tag on EVERY object. Something I don't think should be allowed!
>

Agree - I think a bot injecting wikipedia/wikidata tags based on some
heuristics, e.g. "has the same object class and is nearby" is not very good
and error prone. This could be a human-curated process, e.g. ask the user
to help deciding which  Wikipedia articles does this object represent, and
offer some likely candidates, but it shouldn't be automatic.  I think
Mapbox was working on something like that?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Yuri Astrakhan]

Andy, both sr: and sq: languages describe the same CONCEPT - "republic of
Serbia".  Both articles mention Kosovo as a territory with the special
status.  So the content is the same, and both can be used to describe the
ground truth of Republic of Serbia. The articles just choose to show a
slightly different map image -- but that's exactly where OSM comes in - we
are the ones who can draw the ground truth correctly, and simply reference
the object to the Wiki.  Or should we base OSM data on Wikipedia?

If we draw two OSM objects - with Kosovo and without, we ourselves step
into the ground truth debate, and need to decide which object corresponds
to the Wiki article better, or perhaps mark both with the same Wikipedia
article. Again, this debate is mostly about disputed territories and how to
tag them, not the Wiki* links.

On Mon, Oct 23, 2017 at 7:33 AM, Andy Townsend  wrote:

> On 23/10/2017 11:40, Ryszard Mikke wrote:
>
>> That seems like a problem to fix in Wikipedia
>>
>
> Part of the problem is that some of these problems simply aren't fixable
> at wikipedia.  For example https://sr.wikipedia.org/wiki/
> %D0%A1%D1%80%D0%B1%D0%B8%D1%98%D0%B0 and https://sq.wikipedia.org/wiki/
> Serbia are allegedly the same article and https://www.wikidata.org/wiki/
> Q403 lists them both. However, as can be seen by looking at the maps on
> each page, they aren't the same geographic entity - one includes Kosovo,
> one does not.  Neither is "wrong" from the point of view of the authors of
> each page yet they can't both be "correct" at the same time.
>
> Best Regards,
> Andy
>
>
>
> ___
> 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 OSM Quick-Fix service

[Yuri Astrakhan]

@mmd, thanks, but I never said anything about oneway=no, and never proposed
to remove it.  Andy Townsend introduced that into the discussion, and JB
elaborated on it. It is not listed in the deprecated list, nor is it in
JOSM autofixes, so it is a moot point.  BTW, I did find oneway=1 ->
oneway=yes JOSM autofix and added it to Sophox (about 4,250 hits)  here


@JB, my only goal with this effort is to reduce the amount of work data
consumers must do to use our data, as I believe this to be a significant
enough problem that raises barrier of entry. You are right that =0 and =no
seem like nobrainers, but if we have listed them as deprecated, we should
not use them. Otherwise - why deprecate, if they still contain meaning?
Perhaps they are bad for discussing Sophox itself, and we should pick some
other deprecated or JOSM autofix.

Second, there is no mechanical edits here. Lets not dilute the meaning of
the words, otherwise eventually almost anything can be called that. These
are tasks, or "challenges", that allows users to review each case
independently, either agree, pick one of the solutions, or mark as invalid.
Some cases can be resolved based on the existing information, e.g. other
tags / satellite imagery / reading OSM wiki / local knowledge / visiting
other web sites.  Some cases require in-person visit to the location.
Sophox is not a magic bullet that will solve all such cases, it is just a
tool to fix some of the existing issues.

If someone points out a problem, surely it's better for the
> developer to think about whether they have a point, about whether your
> software should act this way, rather than just saying "But JOSM does it!".
>
Rory, I agree that any problem raised should be analyzed. At the same time,
if an accepted tool already does something in a certain way, and noone is
raising any objections to it, I think other software should follow in the
same foot steps. Because otherwise we are saying that only existing tool
could have an otherwise discouraged practice.

> Do *you* think removing layer=0 is a good idea? What is the objection to
> removing it?
>
I think that if the community deprecates anything, it should eventually be
fixed. Otherwise we keep creating multiple ways of specifying things, and
each data consumer must understand each of them, making it progressively
harder to parse, and raising the entry bar. This is a general statement
about all deprecation, not specifically layer=0.
The objections stated by Andy are that there *could* be cases when it is
useful to indicate that something exists above/below, but hasn't been drawn
yet.  This might be a valid objection (even though it was not backed up by
any specific examples), but 1) if it caries valid info, why was it
deprecated? 2) how widespread is this usecase? 3) why are we using
deprecated tags to indicate a problem, instead of using fixme= or note= ?
4) With the existing tooling (JOSM), there are very high chances that
someone would delete this tag without realizing it is needed for something.
My tool offers a way to spot and highlight it - shouldn't we use it asap to
find all such cases?

>
> Just because someone else does a bad thing doesn't mean you have to copy
> them. Is your tool merely "JOSM validator, but with SPARQL and on the web"?
>
I haven't heard anyone saying that JOSM validator autofixes do a bad thing
until this conversation. Do you think they are bad? Richard Fairhurst said
that JOSM has been exemplary in matching community editing approaches, and
Jo Hannes mentioned that JOSM's devs are always ready to fix any kind of
issue.  So lets agree - either this is a good feature, in which case other
tools should follow similar approaches, or it's bad, in which case we
should file bug reports, and other tools should rectify it - which Sophox
tries to do already.

My tool goals are listed here, and they have very little to do with SPARQL:
https://wiki.openstreetmap.org/wiki/Sophox#Sophox_design_goals
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yuri Astrakhan]

JB, try to avoid swearword outburst, not helpful.  Are you taking issue
with the word "deprecated"?   The proper word should probably have been
"unnecessary" to discuss the layer=0, per JOSM's naming:
https://josm.openstreetmap.de/browser/josm/trunk/data/validator/unnecessary.mapcss

The wiki deprecation only lists one =no:  highway=no, but we are not
discussing that one yet --
https://wiki.openstreetmap.org/wiki/Deprecated_features

I used the word "deprecated" in a more general term, to mean anything that
community has decided to phase out, such as JOSM autofixes and deprecation
list.

I have no   clue what you meant otherwise about mixing issues. I am
attempting to answer every possible question being raised. So far there has
been a few very constructive and helpful emails, and lots of sidetracks. If
you want to stay focused, re-read my initial post, as well as my most
latest post with the new tool capabilities, or just read the Sophox wiki
page and try to follow the style of Simon & Tobias - both have raised valid
objections, and in both cases it resulted in tool's improvements.

On Mon, Nov 13, 2017 at 3:05 AM, JB <jb...@mailoo.org> wrote:

> Le 13/11/2017 à 01:16, Yuri Astrakhan a écrit :
>
>> You are right that =0 and =no seem like nobrainers, but if we have listed
>> them as deprecated, we should not use them.
>>
> Deprecated? Where did you find that?
> (Swearwords somewhere here. Did someone already said that you mix issues?)
>
> ___
> 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 OSM Quick-Fix service

[Yuri Astrakhan]

Christoph, I don't think this works for any community that grows beyond a
certain size, especially when the community is not in the same
location/building/land otherwise, and doesn't see each other every day.
Look at Wikipedia, or any large social organization for that matter. At the
village/startup level, you have very few codified rules, but as the group
grows to a city/corporation size, it becomes more and more bureaucratic. We
may not like it, but clear rules help community maintain cohesion, and
prevents many conflicts.


On Mon, Nov 13, 2017 at 7:04 AM, Christoph Hormann <o...@imagico.de> wrote:

> On Monday 13 November 2017, Yuri Astrakhan wrote:
> > Christoph, thanks for clarifying.  I should have been a bit more
> > careful with that word.  Could you clarify one thing - if wiki is not
> > authoritative for deprecation, than what is?  "Community consensus
> > that something is not to be used" has to be documented somewhere,
> > right?
>
> No, it does not have to.  It is the nature of most societies that not
> all social rules that exist are also codified.  The process of becoming
> a member of the OSM community to a large part consists of becoming
> familiar with and developing an intuitive understanding of the
> unwritten rules.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yuri Astrakhan]

Christoph, thanks for clarifying.  I should have been a bit more careful
with that word.  Could you clarify one thing - if wiki is not authoritative
for deprecation, than what is?  "Community consensus that something is not
to be used" has to be documented somewhere, right?

Per https://wiki.openstreetmap.org/wiki/Automated_edits

*Automated edits* and *semi-automated edits* (sometimes called *mechanical
edits*) are changes made to OpenStreetMap content with no or very limited
human oversight, including those made by bots
, algorithmic processes, imports
 and also major
changes made using general-purpose map editing tools such as JOSM
.


This differs from your own definition. The wiki definition does not discuss
which features are being edited, or how I pick what to edit. It
concentrates on the oversight - if I oversee each change one by one, and
pay attention to it, by the above definition it is not an automated, nor a
mechanical edit. A bot is an automated edit. Loading things into JOSM, and
renaming 100 instances of tag "foo" into "bar" is a semi automated
(mechanical) edit, because both lack oversight for each change.

JD, The whole layer=0 conversation started with this message:

I have copied some of the JOSM & deprecation autofixes as Sophox tasks
> (quick fixes page). *Which of them would be good for the first review? *It
> should probably be more obvious, like replacing identical
> maxspeed:forward+maxspeed:backward with maxspeed tag, or removing
> layer=0, etc.
>
> As you can see, it was a call for a balanced discussion on what would be
good to fix, in a way Map Roulette and other fixing tools do it.  Instead,
we are now discussing if layer=0 and semantics.  I agree that using words
correctly is paramount to understanding each other, but if we target one
example, and blow it into multiple messages, it helps no one.


> I only think I will print Frederick's mails, and regularly read them again
> and again.
>
Frederick's mail have been very passionate, and they would be great for
uniting people for a cause, but I don't think they were as productive or
consensus reaching as some other emails. Vilifying your opponent does not
help the discussion - we are talking about ideas and tools, not persons.
Otherwise we end up with Facebook's opinion bubble, where both sides sit in
their own hall of mirrors, and don't try to reach any mutual understanding.


> I will not answer anymore to this thread. It feels too much like a
> scientific paper submission: If you answer to every objection, even
> sometimes with halt-truth, there will come a time when there is no more to
> say.
>

Using a word with a slightly different meaning is not the same as a
half-truth. Half-truth implies a lie. If you think I have lied or mislead,
say so, and explain where. Otherwise, this is baseless accusations.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yuri Astrakhan]

Joseph, we are mixing multiple issues: interface and the actual tasks.
Sophox interface is very similar to MapRoulette and Osmose in terms of
viewing issues.  You see issues everywhere on the planet, and you are
invited to edit them anywhere you like.

The "pick from choices" approach is also not new.  Tools like
osm.wikidata.link offer users a selection of choices, and allows to pick
the right match. Sophox goes a step beyond that, allowing disputed tasks to
have votes in addition to editing directly.

To demo the tool, I wrote a few tasks based on JOSM validations and
deprecation list.  But they can be anything, suggested by anyone in the
community. This is again similar to MapRoulette, where anyone can create a
challenge, and that challenge is not restricted to a location.

If you disagree that these specific challenges should exist - sure, that
would be a valid argument.  As long as we don't single out a specific tool,
but rather say "challenges such as X should not exist in any of the tools.
Challenges such as Y are ok."

On Tue, Nov 14, 2017 at 6:12 AM, Joseph Reeves <iknowjos...@gmail.com>
wrote:

> "Andy, as I stated before, JOSM doesn't force you to edit in your area -
> it shows you whatever data you download."
>
> This isn't quite true, or rather, you're not understanding how people map.
>
> JOSM will let you edit any data in the world, but you have to be
> interested in that area first: I can be sat in England and download a
> village on the other side of the world, but I have to go and do it.
>
> So if I fix up errors in JOSM in a geographic area that I'm not currently
> sat it, it's because I have an interest in that geographic area, not in
> JOSM validation rules.
>
> There is no "random page" button in JOSM.
>
> Wikipedia would be different: it's easy to see differences in Wikipedia
> between content and grammar, so you could easily swap out every mention of
> "color" for "colour" on en-gb pages whilst leaving the subject matter
> coherent.
>
> You seem to be confusing the content and the grammar of OSM and have
> provided a tool to make changes world wide - outside of people's areas of
> geographic interest or expertise - that is at risk of damaging the actual
> OSM "subject".
>
> From reading most of the posts in these interminable threads it appears
> that you do not understand how OSM, and the people that make it, actually
> works.
>
> This is ok; personally I'm not interested in Wikipedia editing, so I
> don't. I don't want to apply OSM style practices to Wikipedia as I know
> there's a whole world of people there doing their own thing. It doesn't
> have to go both ways.
>
> In short, I have looked at your tool and don't think it is currently
> beneficial to the OSM ecosystem. The discussions ongoing here suggest it
> won't ever be.
>
> Thanks, Joseph
>
>
>
>
> On 13 Nov 2017 21:22, "Yuri Astrakhan" <yuriastrak...@gmail.com> wrote:
>
> On Mon, Nov 13, 2017 at 2:52 PM, Andy Townsend <ajt1...@gmail.com> wrote:
>
>> On 13/11/2017 19:36, Yuri Astrakhan wrote:
>>
>> > That's why I think Sophox is a much better and safer alternative to
>> JOSM's autofixes.
>>
>> At the risk of repeating something that's been said multiple times
>> previously, with JOSM autofixes you're performing edits in an area where
>> you've already edited.  You're presumably somewhat familiar with what's
>> there (you may even have actually visited in person and seen what it looks
>> like on the ground). With your "tool" you're simply performing a mechanical
>> edit with no experience of the underlying data.
>>
>
> Andy, as I stated before, JOSM doesn't force you to edit in your area - it
> shows you whatever data you download. OverpassT can provide it to JOSM
> anywhere too. Your query in Sophox can be limited to an area, or can be
> anywhere - it all depends on the task's query. Also, you keep misusing the
> word "mechanical edit" (per wiki definition, see my other email).  Don't
> dilute the term.
>
> My main point remains - doing a "by-the-way fixing" is worse than
> dedicated effort to fix one issue at a time. Tagging experts who studied
> specific issue, and who reviewed all relevant wiki notes and comment are
> better than a local user who auto-accepts all JOSM-suggested fixes because
> they sound reasonable, but who might have missed all the nuances of the
> specific tag change. This makes it unrevertable and impossible to find.
> Also, it's bad because if a user doesn't accept them, a subsequent editor
> eventually will.  Local expertise needs to be balanced with tagging task
> expertise - and sorry, there is no unicorn, 

Re: [OSM-talk] weeklyOSM #382 2017-11-07-2017-11-13

[Yuri Astrakhan]

Christoph, unregenerate implies I should apologize for doing a wrong thing.
In the discussion, the only thing I **actually did** was I wrote a new tool
and posted about it.  Was I wrong to write a tool?  Was I wrong to discuss
it with the community?

I patiently sifted through all the negative comments and addressed the
issues. I address Fredrerick's issue about zoom, I addressed Andy's comment
about domain name  and lack of https, I listened to Simon's comment about
reject button.  I simplified DWG's ability to find and revert relevant
changesets.  And many other issues.

Should I apologize for not listening? But as you can clearly see from all
the changes, I listened very attentively, and tried to address every single
point. Should I apologize for writing software that uses the same concepts
and ideas as other similar tools? Should I apologize for holding a
different opinion than some of the community, while clearly supported by,
perhaps a less vocal minority?

On Wed, Nov 22, 2017 at 7:32 PM, Christoph Hormann  wrote:

> On Wednesday 22 November 2017, Richard Fairhurst wrote:
> >
> > Worth noting that WeeklyOSM is produced alongside and seeded by the
> > German Wochennotiz. I don't sprechen sufficient Deutsch to be
> > certain, but it looks like the German original[1] is more carefully
> > worded and less presumptuous. So the controversial second half is
> > very possibly just a clumsy translation.
>
> For understanding - and i don't want to support any further attempts in
> telling the WeeklyOSM team how to do their work with that - the German
> version uses the term 'uneinsichtig' - which might also be translated
> as unregenerate.
>
> My attempt at a translation of the German text would be:
>
> "Yuri is perceived by many in this discussion, in a similar way as in
> previous discussions, as unreasonable/unregenerate and questions the
> relevancy of the unwritten rules of OSM."
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Directed Editing Policy

[Yuri Astrakhan]

Thanks Frederik. This is a good explanation. Can some of it perhaps be
added to the document to make it clearer?

On Wed, Nov 22, 2017 at 6:22 AM, Frederik Ramm <frede...@remote.org> wrote:

> Hi,
>
> On 22.11.2017 04:16, Yuri Astrakhan wrote:
> > Pierre, I suspect the number of QA-tool-driven changes are as big, if
> > not much bigger than changes from the organized events and paid editing.
> > I agree QA tools should be regulated, but are you sure we want to do it
> > in the same document, and significantly increase the scope?
>
> This is something that was discussed at length while drafting the
> policy, and you are certainly right, it *is* a difficult area.
>
> The spirit of the policy can largely expressed in "responsibility"
> terms; the policy, by and large, applies whenever the person being
> responsible for an edit is not the person making it.
>
> Most QA tools still require the user to take responsibility. If the QA
> tool says "here's a road that crosses a river without a bridge or ford
> or anything, please check on aerial imagery and apply correct tagging"
> then the responsibility clearly lies with the user. Even if the QA tool
> says "this road is tagged highway=residentail, should it perhaps be
> highway=residential instead?" the responsibility still lies with the
> user. You could go so far as to say: A QA tool that doesn't require the
> user to take responsibility is not a QA tool, it is a distributed
> mechanical edit and as such, covered by its own policy already.
>
> (Of course if I now set up "the great bridge fixing event" where I
> invite people to help me fix all these problems in one weekend, and
> provide detailed instructions to absolute newcomers on how to fix
> bridges, then there might be a point where responsibility shifts to me
> and I am now "directing" these people to use the QA tool to fix things.)
>
> 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

[OSM-talk] Permanent IDs RFC (was part_of:wikidata)

[Yuri Astrakhan]

Permanent IDs has been brought up several times, especially as part of the
Wikidata ID discussion. I started a wiki page to outline the requirements
and goals, but it might be incomplete, feel free to add / correct / comment.

https://wiki.openstreetmap.org/wiki/Permanent_ID

Once we reach the agreement on the goals, we can figure out the
implementation strategy.


On Tue, Nov 28, 2017 at 2:47 PM, Andy Mabbett 
wrote:

> On 28 November 2017 at 16:40, Christoph Hormann  wrote:
>
> > The problem is OSM is a map of the physical world, not a map of the
> > world's databases.  If Wikidata wants to create links between OSM and
> > other databases that is great but so far i think no one has made a good
> > case why this linking information should be stored in OSM rather than
> > Wikidata.
>
> Then you are not paying attention. OSM IDs are volatile - far more
> volatile than Wikipedia IDs, let alone Wikidata IDs.
>
> > Again my suggestion: Working on better ways to address features in OSM
> > in a stable way from the outside would be much more productive
>
> Great! Let us know when you have a working solution, consensus to
> implement it, and tools that work with it.
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] weeklyOSM #382 2017-11-07-2017-11-13

[Yuri Astrakhan]

Richard, in both languages, the main issue is the same. It says that the
discussion has restarted with the negative commentary, but skips the main
point - that the tool has been substantially reworked based on community
feedback.  It's like saying some people got rich without mentioning the
bank rubbery.  And it alleges that the tool is a "hidden mechanical edit
tool", (GTranslate) which is simply untrue - unless they are claiming that
existing tools are also that.

On Wed, Nov 22, 2017 at 2:08 PM, Richard Fairhurst 
wrote:

> joost schooupe wrote:
> > It doesn't help that it was worded as "people are
> > saying", but then the last part of the sentence seems more
> > like their own opinion.
>
> Worth noting that WeeklyOSM is produced alongside and seeded by the German
> Wochennotiz. I don't sprechen sufficient Deutsch to be certain, but it
> looks
> like the German original[1] is more carefully worded and less presumptuous.
> So the controversial second half is very possibly just a clumsy
> translation.
>
> Reading back through this whole discussion, those of us fortunate enough to
> be born with the world's international language as our mother tongue could,
> perhaps, be more forgiving of those who weren't.
>
> Richard
>
> [1] http://blog.openstreetmap.de/blog/2017/11/wochennotiz-nr-382/
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html
>
> ___
> 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] weeklyOSM #382 2017-11-07-2017-11-13

[Yuri Astrakhan]

One important aspect was missing in the announcement. The tool's new name
is a tiny part of a much bigger set of community suggested and requested
changes. Fully ignoring functionality changes that many community members
suggested is biased.

Mechanical edit claim was also never justified -- saying it's a mechanical
edit tool doesn't fit with the community's own definition, per wiki. Just
the other day the importance of using the right word was mentioned - when I
allegedly missed the word "deprecated". Let's keep things consistent, and
not dilute or change the meaning of existing terms to fit the immediate
agenda.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] weeklyOSM #382 2017-11-07-2017-11-13

[Yuri Astrakhan]

Whataboutism at its best?

John Oliver: https://youtu.be/1ZAPwfrtAFY?t=6m2s


On Fri, Nov 17, 2017 at 7:10 PM, Andy Townsend  wrote:

> On 17/11/2017 22:52, Clifford Snow wrote:
>
>
> Frederik,
> I think we are all thankful for the newsletter. And believe they are free
> to publish to their own standards. However, because they use OSM resources
> by publishing on our mailing lists they need respect our values. I don't
> think asking a publication to be respectful to individuals is asking too
> much.
>
>
> Clifford,
> Being "respectful" is a two-way street.  This is a situation that's been
> going on for almost exactly a year now.  During that time this individual
> has shown contempt for the OSM community, including on occasion telling
> outright untruths.  Conversations with him were very repectful at first
> (conducted in changeset discussions rather than on mailing lists), but it
> gradually became clear that any statements such as "I have already stopped
> changing any objects except" were simply worthless.  At some point you have
> to call a lie a lie, and I can't think of a way of doing that without
> "being disrespectful".
>
> Also, I have to object to the use of "they" and "our" in your comment.
> The OSM Weekly is produced by and for people from the OSM community,
> exactly the same community that the mailing lists are run by and for.  The
> use of that sort of divisive language ("they") reminds me of a visit to
> South Africa back in the 90s, and not in a good way.
>
> Best Regards,
>
> Andy
>
>
> ___
> 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 OSM Quick-Fix service

[Yuri Astrakhan]

While it is easy to throw tons of accusations and be less civil, I will try
maintain my level of decency.  I have forwarded you a snippet of one of the
emails I received (without the sender name). Also, you are welcome to
organize some independent person you trust in NYC to stop by and examine it
in person, and I hope that person will be decent not to disclose the sender.

I am still in this chat, despite the witch hunt. Which implies I do want to
listen, and civilly communicate. The witch hunt is a fun activity for some,
but others do provide useful feedback and comments, and that's why I am
still hopeful.  Note that the ones who offered specific feedback and
suggestions have not spoken yet after the changes, with the exception of
@mmd (thanks!)

Distorting what? I present my case. Most of the arguments are ignored. Tiny
pieces of the emails get blown out of proportion.  I said a) why i do it,
b) why i think its better than existing system, c) how it makes it easier
to review/revert, unlike the current system. And I keep repeating these
things from various angles, explaining that at the end of the day, this
will make OSM better for everyone.  Instead, we are discussing everything
but the above.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yuri Astrakhan]

On Mon, Nov 13, 2017 at 6:02 PM, Michael Reichert <osm...@michreichert.de>
wrote:

> Hi Yuri,
>
> Am 13.11.2017 um 22:58 schrieb Yuri Astrakhan:
> > Andy, I can only assume you agree with the rest of my argument. As for
> this
> > case -- this is not a mechanical edit. Per definition. I looked at each
> of
> > these three features, analyzed them, and thought this is a reasonable
> > change. You could call it a mistake (I am human), but it cannot be called
> > mechanical.
>
> Here comes another of our unwritten rules into play. Even if a
> systematical edit [1] is not a mechanical edit, it is sensible to
> discuss it beforehand as if it were a mechanical edit (although you
> could steps which involve the OSM wiki). This rule is unwritten but
> people who have followed discussions on any relevant mailing list or
> forum section will know it because some other users mentioned it there.
> That's why silently reading discussions for a while before doing
> possibly disruptive things in OSM is recommended (another unwritten rule).
>
> Michael, was there a URL [1] missing?   I 100% agree with you about this
unwritten rule, and that's why I am here too, discussing the tool and the
quick fix tasks. I might disagree with some of the hardliners, but thanks
to the discussion and feedback, Sophox tool has been substantially changed.
Also an existing rule in JOSM has been fixed.

The quick fixes have all been published, and I hope we can agree which ones
are non-conflicting. I do get a lot of animosity instead of fruitful
discussion, but despite that there has been a number of good comments that
helped it improve.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Dropping out, was: New OSM Quick-Fix service

[Yuri Astrakhan]

Frederik, once again you are using your position and mailing list as a
tribune, speaking to others instead of speaking to me.  I posted [1] my
initial idea/tool, and you immediately wrote a large, mostly personal
attack [2], rather than something like [3] - which also criticized, but
helped guide it forward. Most of the issues you mention in [2] have long
been addressed, but you don't care to discuss the actual changes - you
already made up your mind that it's evil, and you haven't replied to a
single attempt at a substantive communication. I even offered to video talk
to you directly, hoping that an understanding could be reached, but alas.

I think your emails strongly polarized community.  I kept changing and
adapting Sophox based on the received feedback, including yours. I don't
think you have ever changed the rhetoric or tried to gain understanding or
a compromise. People come to the project, bring new ideas, and try to fix
issues they see as important to them. Instead of trying to understand and
adapt, several hard-liners have taken the "this is not how it's done around
here" approach, and forced people out.

Accusations are easy - we can spew them thousands at a time. Refuting them
one by one takes much more effort. Saying that I jump topics many times
doesn't make it so.  I am very consistently discussing just one thing -
Sophox [4], and how it can help make OSM better. Tons of people want to
runs bots on OSM, but Sophox tries to find a safe middle ground between
bots and humans, addressing the problems that are clearly there (otherwise
all these tools wouldn't have been created).

[1] https://lists.openstreetmap.org/pipermail/talk/2017-October/079145.html
[2] https://lists.openstreetmap.org/pipermail/talk/2017-October/079146.html
[3] https://lists.openstreetmap.org/pipermail/talk/2017-October/079172.html
[4] https://wiki.openstreetmap.org/wiki/Sophox

On Mon, Nov 13, 2017 at 6:19 PM, Frederik Ramm <frede...@remote.org> wrote:

> Hi,
>
> On 11/13/2017 10:58 PM, Yuri Astrakhan wrote:
> > Andy, I can only assume you agree with the rest of my argument.
>
> Yuri, I think at this point it is time for me to stop reading your
> contributions here. You are not genuinely trying to understand; this is
> just a smoke-screen. You are trying to win an argument here by cleverly
> jumping from topic to topic, putting words in people's mouths, and if
> that's not enough you try to simply write 20x more than anybody else
> hoping to wear everyone out.
>
> This mailing list is not a high school debate club, however much you
> treat it like one, and you've abused OpenStreetMap as your playground
> for far too long already starting when you first lied to me about
> stopping your mass wikidata tag additions. I'm tired of it and I won't
> make any further attempts to explain things to you.
>
> Just in case you are tempted to interpret future silence from me as a
> silent agreement - don't. Ever.
>
> 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 OSM Quick-Fix service

[Yuri Astrakhan]

@mmd,

I have noticed that the proposed fixes were not marked with vote=1. I fixed
them.
https://wiki.openstreetmap.org/wiki/Quick_fixes#Proposed_fixes

I'm not sure if vote=1 is needed for the multiple-choice challenges. They
were originally copied from the officially deprecated tags, so technically
they have already been discussed by the community. Also, I would think that
the person who changes amenity=education to college/school/university has
to have the local knowledge, or find business' website and research it
there?  Either case is fine of course.
https://wiki.openstreetmap.org/wiki/Quick_fixes#Multiple_Choice_Challenges

Lastly - in case of a manual edit (power mode), Sophox will set
"task_id=manual" to make them easier to find.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yuri Astrakhan]

On Mon, Nov 13, 2017 at 8:50 AM, Rory McCann <r...@technomancy.org> wrote:

> On 13/11/17 01:16, Yuri Astrakhan wrote:
>
>> if an accepted tool already does something in a certain way, and noone is
>> raising any objections to it, I think other software should follow in the
>> same foot steps.
>>
> > ...
>
>> I haven't heard anyone saying that JOSM validator autofixes do a bad
>> thing until this conversation. Do you think they are bad?
>>
>
> Yes, sometimes! I looked at your fixes, saw one that didn't make sense,
> (about unisex toilets) followed it to the JOSM validator, filed a bug which
> seems to be fixed ( https://josm.openstreetmap.de/ticket/15536 ).
>
> JOSM isn't perfect, "many eyes make all bugs shallow" etc.
>
> Great, thanks for spotting it! I will update the Sophox task shortly as
well.
But my statement about "tool doing something in a certain way" is not about
the specific task - as they can be buggy in every tool. I was talking about
the overall JOSM autofix approach that Sophox copies and attempts to
improve. I don't think your example argues against that.

On the contrary, your example shows that it is much better to have these
tasks standalone, with an expert oversight.  Right now you have no easy way
to find when users have auto-fixed the bathrooms using JOSM - there could
be none, or thousands.  And they are mixed together with other changes,
making it nearly impossible to revert. With Sophox, you can instantly find
them all, and review/revert them - simply search changsets for
task_id=josm_unisex_female_male_dup.  That's why I think Sophox is a much
better and safer alternative to JOSM's autofixes.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] What would make MapRoulette better?

[Yuri Astrakhan]

Martijn, I think this is very similar to what Osmose does in its DB view
(and I think several other tools do in the map view) - they offer a choice
of a "world view" (unfiltered) or a "region views" - where users may choose
what region they are interested in (e.g. a dropdown).

I think it would be better for MR to offer users an automatic preset region
filtering, rather than requiring each challenger author to create regional
sub-challenges.

On Mon, Nov 20, 2017 at 3:48 PM, Martijn van Exel  wrote:

> Marc,
>
> Good point and something that has come up often.
> As Joost mentioned in a reply, the easy solution for this is, as a
> challenge owner, to split up the challenge into regional chunks and label
> them as such.
>
> The new version will have ‘filter by current map bounds’. I’m not quite
> sure how to best do this yet. One solution would be to filter by challenge
> ‘centroids’ (simple), another would be to consider whatever challenge has
> at least one task within the current map bounds (harder). What would be
> your idea about this? Others with an opinion?
> --
> Martijn van Exel
>
> On November 20, 2017 at 9:58:40 AM, Marc Gemis (marc.ge...@gmail.com)
> wrote:
> > The possibility to work more locally. E.g. there is a project to add
> > missing roads in Belgium, I would really like to see only the "issues"
> > within let say 20km of my house (an arbitrary point I can set).
> >
> > m.
> >
> > On Sun, Nov 19, 2017 at 9:59 PM, Martijn van Exel wrote:
> > > Hi all,
> > >
> > > For those who have used MapRoulette or at least have a good
> understanding of
> > > what it does: what would be the *one top thing* for you that would
> make it
> > > better?
> > >
> > > I am asking because I am working on a new major release.
> > > --
> > > Martijn van Exel
> > >
> > > ___
> > > 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] weeklyOSM #382 2017-11-07-2017-11-13

[Yuri Astrakhan]

James, this is not about hurt feelings. This is about misrepresentation.

Last week I re-wrote Sophox tool based on the community feedback. The new
tool uses the same approaches as existing tools. Yet, somehow I violated
some unwritten rule by creating a new tool?  This is bogus.

There were many OSM edits I have done in the past. Some of them might have
broken the rules. How does that relate to the new tool discussion?  The
conversation was about the new tool that does things the same way as
several other tools.

How does that break "unwritten rules"?

On Sat, Nov 18, 2017 at 5:24 AM, James  wrote:

> Seriously this is what 2017 has become? A bunch of snowflakes argueing
> whoes feelings are hurt? Seriously grow up people, the world is not full of
> cupcakes and rainbows.
>
> "Yuri is perceived by many as unreasonable as before and tries to ignore
> all the unwritten rules in OSM."
>
> I was somewhat following that email thread and there were many people
> sayong that yuri was unreasonable and that he was ignoring the rules for
> mechanical edits. Journalists are allowed to summarize the general tone of
> a situation without being perceived as "taking sides".
>
> On Nov 17, 2017 10:49 PM, "Clifford Snow"  wrote:
>
>> Andy,
>>
>> On Fri, Nov 17, 2017 at 4:10 PM, Andy Townsend  wrote:
>>
>>> On 17/11/2017 22:52, Clifford Snow wrote:
>>>
>>>
>>> Frederik,
>>> I think we are all thankful for the newsletter. And believe they are
>>> free to publish to their own standards. However, because they use OSM
>>> resources by publishing on our mailing lists they need respect our values.
>>> I don't think asking a publication to be respectful to individuals is
>>> asking too much.
>>>
>>>
>>> Clifford,
>>> Being "respectful" is a two-way street.  This is a situation that's been
>>> going on for almost exactly a year now.  During that time this individual
>>> has shown contempt for the OSM community, including on occasion telling
>>> outright untruths.  Conversations with him were very repectful at first
>>> (conducted in changeset discussions rather than on mailing lists), but it
>>> gradually became clear that any statements such as "I have already stopped
>>> changing any objects except" were simply worthless.  At some point you have
>>> to call a lie a lie, and I can't think of a way of doing that without
>>> "being disrespectful".
>>>
>>
>> Absolutely. I'm only suggesting that as a community we strive to be
>> respectful to everyone, all the time. That in no way mean that we condone
>> bad behavior. I'm all for calling out such behavior even to the point of
>> expelling/banning the person if reasonable attempts to get the person to
>> change is futile. My basic belief is that all people have good intentions.
>> Our community goal should be to bring out the best in everyone.
>>
>>
>>>
>>> Also, I have to object to the use of "they" and "our" in your comment.
>>> The OSM Weekly is produced by and for people from the OSM community,
>>> exactly the same community that the mailing lists are run by and for.  The
>>> use of that sort of divisive language ("they") reminds me of a visit to
>>> South Africa back in the 90s, and not in a good way.
>>>
>>
>> Sorry for the poor choice of words. Now you see why I don't offer to edit
>> or write for the OSM Weekly.  My grandfather, a former newspaper editor,
>> would have been sadden by my lack of writing abilities.
>>
>> Best,
>> Clifford
>>
>> --
>> @osm_seattle
>> osm_seattle.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
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] weeklyOSM #382 2017-11-07-2017-11-13

[Yuri Astrakhan]

John, not trusting a brand name and being unreasonable about new project
are two different things.  One is a healthy caution. The other is a
baseless witch hunt, at which point it doesn't matter what the person does,
what matters are the pitch forks and torches.

On Sat, Nov 18, 2017 at 1:19 PM, john whelan <jwhelan0...@gmail.com> wrote:

> >There were many OSM edits I have done in the past. Some of them might
> have broken the rules. How does that relate to the new tool discussion?
> The conversation was about the new tool that does things the same way as
> several other tools.
>
> How does that break "unwritten rules"?
>
> It relates to trust and politics with a small p.  Your brand name is
> untrusted.
>
> Cheerio John
>
> On 18 November 2017 at 13:11, Yuri Astrakhan <yuriastrak...@gmail.com>
> wrote:
>
>> James, this is not about hurt feelings. This is about misrepresentation.
>>
>> Last week I re-wrote Sophox tool based on the community feedback. The new
>> tool uses the same approaches as existing tools. Yet, somehow I violated
>> some unwritten rule by creating a new tool?  This is bogus.
>>
>> There were many OSM edits I have done in the past. Some of them might
>> have broken the rules. How does that relate to the new tool discussion?
>> The conversation was about the new tool that does things the same way as
>> several other tools.
>>
>> How does that break "unwritten rules"?
>>
>> On Sat, Nov 18, 2017 at 5:24 AM, James <james2...@gmail.com> wrote:
>>
>>> Seriously this is what 2017 has become? A bunch of snowflakes argueing
>>> whoes feelings are hurt? Seriously grow up people, the world is not full of
>>> cupcakes and rainbows.
>>>
>>> "Yuri is perceived by many as unreasonable as before and tries to ignore
>>> all the unwritten rules in OSM."
>>>
>>> I was somewhat following that email thread and there were many people
>>> sayong that yuri was unreasonable and that he was ignoring the rules for
>>> mechanical edits. Journalists are allowed to summarize the general tone of
>>> a situation without being perceived as "taking sides".
>>>
>>> On Nov 17, 2017 10:49 PM, "Clifford Snow" <cliff...@snowandsnow.us>
>>> wrote:
>>>
>>>> Andy,
>>>>
>>>> On Fri, Nov 17, 2017 at 4:10 PM, Andy Townsend <ajt1...@gmail.com>
>>>> wrote:
>>>>
>>>>> On 17/11/2017 22:52, Clifford Snow wrote:
>>>>>
>>>>>
>>>>> Frederik,
>>>>> I think we are all thankful for the newsletter. And believe they are
>>>>> free to publish to their own standards. However, because they use OSM
>>>>> resources by publishing on our mailing lists they need respect our values.
>>>>> I don't think asking a publication to be respectful to individuals is
>>>>> asking too much.
>>>>>
>>>>>
>>>>> Clifford,
>>>>> Being "respectful" is a two-way street.  This is a situation that's
>>>>> been going on for almost exactly a year now.  During that time this
>>>>> individual has shown contempt for the OSM community, including on occasion
>>>>> telling outright untruths.  Conversations with him were very repectful at
>>>>> first (conducted in changeset discussions rather than on mailing lists),
>>>>> but it gradually became clear that any statements such as "I have already
>>>>> stopped changing any objects except" were simply worthless.  At some point
>>>>> you have to call a lie a lie, and I can't think of a way of doing that
>>>>> without "being disrespectful".
>>>>>
>>>>
>>>> Absolutely. I'm only suggesting that as a community we strive to be
>>>> respectful to everyone, all the time. That in no way mean that we condone
>>>> bad behavior. I'm all for calling out such behavior even to the point of
>>>> expelling/banning the person if reasonable attempts to get the person to
>>>> change is futile. My basic belief is that all people have good intentions.
>>>> Our community goal should be to bring out the best in everyone.
>>>>
>>>>
>>>>>
>>>>> Also, I have to object to the use of "they" and "our" in your
>>>>> comment.  The OSM Weekly is produced by and for people from the OSM
>>>>> community, exactly the sa

Re: [OSM-talk] weeklyOSM #382 2017-11-07-2017-11-13

[Yuri Astrakhan]

John, are you claiming the entire conversation last week had nothing to do
with the merits of the tool itself? That's a very sad statement.

"building up trust" implies actions. Creating a tool that mimics what other
tools already do implies exactly that. Ignoring the actual tool, and
instead concentrating on the person is exactly what I said before - its a
witch hunt.

On Sat, Nov 18, 2017 at 1:42 PM, john whelan <jwhelan0...@gmail.com> wrote:

> No you need to build up trust again and it takes time.  Only then will
> your ideas start to gain acceptance.
>
> Cheerio John
>
> On 18 November 2017 at 13:26, Yuri Astrakhan <yuriastrak...@gmail.com>
> wrote:
>
>> John, not trusting a brand name and being unreasonable about new project
>> are two different things.  One is a healthy caution. The other is a
>> baseless witch hunt, at which point it doesn't matter what the person does,
>> what matters are the pitch forks and torches.
>>
>> On Sat, Nov 18, 2017 at 1:19 PM, john whelan <jwhelan0...@gmail.com>
>> wrote:
>>
>>> >There were many OSM edits I have done in the past. Some of them might
>>> have broken the rules. How does that relate to the new tool discussion?
>>> The conversation was about the new tool that does things the same way as
>>> several other tools.
>>>
>>> How does that break "unwritten rules"?
>>>
>>> It relates to trust and politics with a small p.  Your brand name is
>>> untrusted.
>>>
>>> Cheerio John
>>>
>>> On 18 November 2017 at 13:11, Yuri Astrakhan <yuriastrak...@gmail.com>
>>> wrote:
>>>
>>>> James, this is not about hurt feelings. This is about misrepresentation.
>>>>
>>>> Last week I re-wrote Sophox tool based on the community feedback. The
>>>> new tool uses the same approaches as existing tools. Yet, somehow I
>>>> violated some unwritten rule by creating a new tool?  This is bogus.
>>>>
>>>> There were many OSM edits I have done in the past. Some of them might
>>>> have broken the rules. How does that relate to the new tool discussion?
>>>> The conversation was about the new tool that does things the same way as
>>>> several other tools.
>>>>
>>>> How does that break "unwritten rules"?
>>>>
>>>> On Sat, Nov 18, 2017 at 5:24 AM, James <james2...@gmail.com> wrote:
>>>>
>>>>> Seriously this is what 2017 has become? A bunch of snowflakes argueing
>>>>> whoes feelings are hurt? Seriously grow up people, the world is not full 
>>>>> of
>>>>> cupcakes and rainbows.
>>>>>
>>>>> "Yuri is perceived by many as unreasonable as before and tries to
>>>>> ignore all the unwritten rules in OSM."
>>>>>
>>>>> I was somewhat following that email thread and there were many people
>>>>> sayong that yuri was unreasonable and that he was ignoring the rules for
>>>>> mechanical edits. Journalists are allowed to summarize the general tone of
>>>>> a situation without being perceived as "taking sides".
>>>>>
>>>>> On Nov 17, 2017 10:49 PM, "Clifford Snow" <cliff...@snowandsnow.us>
>>>>> wrote:
>>>>>
>>>>>> Andy,
>>>>>>
>>>>>> On Fri, Nov 17, 2017 at 4:10 PM, Andy Townsend <ajt1...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On 17/11/2017 22:52, Clifford Snow wrote:
>>>>>>>
>>>>>>>
>>>>>>> Frederik,
>>>>>>> I think we are all thankful for the newsletter. And believe they are
>>>>>>> free to publish to their own standards. However, because they use OSM
>>>>>>> resources by publishing on our mailing lists they need respect our 
>>>>>>> values.
>>>>>>> I don't think asking a publication to be respectful to individuals is
>>>>>>> asking too much.
>>>>>>>
>>>>>>>
>>>>>>> Clifford,
>>>>>>> Being "respectful" is a two-way street.  This is a situation that's
>>>>>>> been going on for almost exactly a year now.  During that time this
>>>>>>> individual has shown contempt for the OSM community, including on 
>>>>>>> occasion
>>>>>

Re: [OSM-talk] Directed Editing Policy

[Yuri Astrakhan]

Pierre, I suspect the number of QA-tool-driven changes are as big, if not
much bigger than changes from the organized events and paid editing. I
agree QA tools should be regulated, but are you sure we want to do it in
the same document, and significantly increase the scope?

My understanding is that the original goal was to regulate paid editing and
community events. Covering QA tools might make the doc too generic.  It
would have to take a detailed look at all existing tools, even including
JOSM's validators -- if I edit a location (e.g. move a road), and the tool
suggests additional edits in that location (e.g. change the tagging of a
connected road), isn't that directed editing that was organized by the
validation rule author? Plus the introduction, and a lot of text would have
to be rewritten to dedicate as much space to the tools as to organized
events and director's duties.

Just saying that the scope creep might make the statement less concise, and
QA tools may need to be a separate document.

On Tue, Nov 21, 2017 at 9:44 PM, Pierre Béland <pierz...@yahoo.fr> wrote:

> There is a constant increae of organized contributions from Task Managers
> on QA tools and I agree that this policy should include these various
> organized contributions.
>
> There should be a goal assure the follow-up of these various projects to
> assure a better collective coordination of the mapping.
>
> I am not sure that we could effectively have all organizers of Events
> create a wiki page. But organizers like for example the Geoweek, that
> invite to create local events should have a wiki page well documented. A
> section could be added to list the specific events + who organize them.
>
> The Changeset database is the place where we should be able to follow the
> various mapping projects. There is actually no common way to document the
> QA or TM host, the specific project and the various events connecting to
> the various projects. To document how these various coordination tools
> should be reported  on the changesets would facilitate the follow-up.
>
> Actually, not all instances of the Tasking Manager add an hashtag to
> document the host and project no. For QA tools, specific projects /
> missions are not documented either.
>
>
> Pierre
>
>
> Le mardi 21 novembre 2017 21:21:55 HNE, Yuri Astrakhan <
> yuriastrak...@gmail.com> a écrit :
>
>
> While this might not have been the intention, the
>
>   >  b) directed by a third party exactly what and how to contribute to
> OpenStreetMap
>
> can be applied to any "challenge style" sites such as the MapRoulette or
> Osmose.  I think there should either be a clarification about this, an
> additional discussion with the community, or a specific exclusion.  I know
> that the preamble is talking about paid editing, schools, and mapping
> events, but the text below it seems to have a wider scope.
> penstreetmap.org/listinfo/talk
> <https://lists.openstreetmap.org/listinfo/talk>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Directed Editing Policy

[Yuri Astrakhan]

While this might not have been the intention, the

  >  b) directed by a third party exactly what and how to contribute to
OpenStreetMap

can be applied to any "challenge style" sites such as the MapRoulette or
Osmose.  I think there should either be a clarification about this, an
additional discussion with the community, or a specific exclusion.  I know
that the preamble is talking about paid editing, schools, and mapping
events, but the text below it seems to have a wider scope.

On Tue, Nov 21, 2017 at 8:23 PM, Mateusz Konieczny 
wrote:

> > This policy applies as soon as someone is
> > directed by a third party exactly what and how to contribute to
> > OpenStreetMap.
>
> Maybe it would be a good idea to exclude small scale guided
> editing. For example my friend asked me to show how OSM worked.
>
> I showed him/her a map and asked to find something missing or mistake
> and later showed how to add this.
>
> It was clearly a guided editing as defined here - and I am not going to
> set up wiki pages etc before doing this the next time.
>
> ---
>
> Other situation where somebody wanted to to delete object from map and
> asked for help would be probably saved by and in "what and how" - (s)he
> had an idea what should be changed.
>
> ___
> 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 OSM Quick-Fix service

[Yuri Astrakhan]

@mmd, thanks, inline:

On Mon, Nov 13, 2017 at 5:32 PM, mmd  wrote:

> > * Added voting - experimental tasks require two users agreement to
> change DB
>
> I assumed this to be a mandatory part of the new process. However, some
> recent edits made by a "Serbian OSM Lint bot" [1] via your tool
> indicates that you can skip pretty much all of those safeguards, and
> still be able to run mass updates without any kind of voting, two user
> agreement, etc. Not sure, if this is intentional, or a bug.
>

The voting is meant to be used by the task authors when they publish
experimental tasks to the community. For example, if I write a new,
possibly contentious task that might cause significant disruption, and
decide to publish it to a large community, I should enable voting for that
task by setting "vote": true -- especially because most of the users might
not be experts in the specific change. If I simply use Sophox as my own
power editor, instead of JOSM/Level0/...,  I would edit things directly,
and follow the same rules as set for the rest of the community. In this
case, Serbian OSM Lint bot simply makes these changes directly. I think
that person used to add name:sr with a custom script and/or by hand, and
now simply uses Sophox for their work.

> * Made it simple to revert Sophox changes: changesets now contain
> > "task_id" to track task-related edits.
>
> Also, this seems to be optional:
> https://www.openstreetmap.org/changeset/53753685 has task_id =
> "undefined" and was editing via Sophox 0.5. Isn't this case handled in
> your tool to forbid creating such changesets in the first place?
>

This change was not done as part of a task, it was done in the "power
editor" mode (as described above).  I think task_id should be set to
something else though, instead of undefined, to indicate that the user is
using it in the power mode, and takes personal responsibility for all
changes. Or I could simply not add the task_id tag in those cases. BTW, I
think they should still use taskId in addition to the comment to better
track their work.

BTW, it is not possible to run a task without task id in a published
(embed) mode.  You can only run it as a task developer by hand (by editing
the query, clicking run button, and scrolling down into the results section)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yuri Astrakhan]

On Mon, Nov 13, 2017 at 2:52 PM, Andy Townsend <ajt1...@gmail.com> wrote:

> On 13/11/2017 19:36, Yuri Astrakhan wrote:
>
> > That's why I think Sophox is a much better and safer alternative to
> JOSM's autofixes.
>
> At the risk of repeating something that's been said multiple times
> previously, with JOSM autofixes you're performing edits in an area where
> you've already edited.  You're presumably somewhat familiar with what's
> there (you may even have actually visited in person and seen what it looks
> like on the ground). With your "tool" you're simply performing a mechanical
> edit with no experience of the underlying data.
>

Andy, as I stated before, JOSM doesn't force you to edit in your area - it
shows you whatever data you download. OverpassT can provide it to JOSM
anywhere too. Your query in Sophox can be limited to an area, or can be
anywhere - it all depends on the task's query. Also, you keep misusing the
word "mechanical edit" (per wiki definition, see my other email).  Don't
dilute the term.

My main point remains - doing a "by-the-way fixing" is worse than dedicated
effort to fix one issue at a time. Tagging experts who studied specific
issue, and who reviewed all relevant wiki notes and comment are better than
a local user who auto-accepts all JOSM-suggested fixes because they sound
reasonable, but who might have missed all the nuances of the specific tag
change. This makes it unrevertable and impossible to find. Also, it's bad
because if a user doesn't accept them, a subsequent editor eventually
will.  Local expertise needs to be balanced with tagging task expertise -
and sorry, there is no unicorn, who knows both perfectly.

In Rory's example - you cannot find who changed what in the past 16 months
for the bathroom autofix. You cannot revert it, because it is mixed with
others. My tool solves that, because experts can review it, and later
experts in that specific issue can review all found cases, and spot
errors.  Even if one person doing a Sophox task spots an error and tags it
as invalid, we can easily notice it and adjust or remove the task, and
easily revert all changes made for that task.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yuri Astrakhan]

Thanks Christoph, I love #386 too.  As I repeatedly stated - my goal is to
allow simpler way for community to fix issues, which in turn would lower
data consumer entry barrier. Not prove someone incorrect (despite the
appearance). Several specific issues and suggestions were raised in this
thread, and they have been resolved. I proposed that we pick a some well
understood tasks for wider review, but instead we got bugged down with
level=0 debate. Many times I stated (what I hope is a) logical argument,
but a few people pick one tiny sentence out of the whole thing and argue
about that, or do a personal attack.  Maybe I should write up an FAQ with
all the arguments raised here, and simply refer to them? It would save on
typing. In the mean time, I receive *multiple* private emails of support
from people who feel intimidated to discuss it here - and I think this is
by far the most significant problem with this discussion, and community
health in general?

On Mon, Nov 13, 2017 at 5:13 PM, Christoph Hormann <o...@imagico.de> wrote:

> On Monday 13 November 2017, Yuri Astrakhan wrote:
> > Andy, I can only assume you agree with the rest of my argument. [...]
>
> If you have made this assumption about anyone who you have communicated
> with in the OSM community in the past you would be well advised to stop
> that and review the views you have developed based on that assumption.
>
> https://xkcd.com/386/ is something something most of us have stopped
> doing relatively soon after we discovered the internet...
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yuri Astrakhan]

Andy, I can only assume you agree with the rest of my argument. As for this
case -- this is not a mechanical edit. Per definition. I looked at each of
these three features, analyzed them, and thought this is a reasonable
change. You could call it a mistake (I am human), but it cannot be called
mechanical.

I have contacted the original author, but haven't heard back.  Judging by
their site, it does look like both a marsh and a monument. You might want
to classify it as something else - that's where the tag expert is needed.
http://gardenseeds.swarthmore.edu/gardenseeds/2017/03/return-of-crumhenge/

On Mon, Nov 13, 2017 at 4:39 PM, Andy Townsend <ajt1...@gmail.com> wrote:

> On 13/11/2017 21:19, Yuri Astrakhan wrote:
>
>
> Andy, as I stated before, JOSM doesn't force you to edit in your area - it
> shows you whatever data you download. OverpassT can provide it to JOSM
> anywhere too. Your query in Sophox can be limited to an area, or can be
> anywhere - it all depends on the task's query. Also, you keep misusing the
> word "mechanical edit" (per wiki definition, see my other email).  Don't
> dilute the term.
>
>
> Unfortunately, a mechanical edit looks exactly like what you're doing -
> see https://www.openstreetmap.org/changeset/53598691 for example.  The
> tags on that as they stand (before or after your edit) don't make a whole
> lot of sense - likely there's a whole bunch of stuff there yet to be
> mapped, and maybe someone more familiar with the area would know if either
> the "memorial" or "marsh" tags make any sense.
>
> Best Regards,
> Andy
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yuri Astrakhan]

Hehe, fun picture, and the article seems to be covering the concept well.
Simon, I don't think anyone was arguing that sanatoriums should be switched
one way or the other globally.  As long as there is a clear conceptual
distinction between two types of features (whichever they are), and that
distinction is documented in a wiki, all is good.  A new mapper should be
told exactly which tags to use for each concept - no matter where in the
world they are.  Guessing the meaning based on the local interpretation of
the tag name/value is not a good approach.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yuri Astrakhan]

The tool has been thoroughly reworked, thanks to many good suggestions.
Please keep discussion to constructive suggestions and ideas - they help us
all move forward and reach agreement.

What's new:
* Tool has a new name: Sophox
* Added "reject" vote button
* Tasks can now offer multiple choices selection (thanks Tobias for the
idea)
* Added voting - experimental tasks require two users agreement to change DB
* Users can "unvote" their own votes
* Multiple changes per changeset
* All votes are stored in the same RDF db, so the task can query it too.
* Added Mapbox satellite imagery
* Made it simple to revert Sophox changes: changesets now contain "task_id"
to track task-related edits.
* Added imagery tag to changeset
* Added domain name & https cert
* Many UI improvements, e.g. login / logoff / unread messages / icons
* Improve query parameter naming

Requirement:  Modern browser (tested on the latest Firefox and Chrome)
Full documentation:  https://wiki.openstreetmap.org/wiki/Sophox

Multiple choice example: changing from amenity=education to a more specific
one, e.g. amenity=school or university.
* http://tinyurl.com/y9tobxm8
​
Single choice example:  removing natural=water from the swimming pools
(should be checked with the satellite view)
* http://tinyurl.com/y84tlqzt

See more examples (single and multi-choice) here:
* https://wiki.openstreetmap.org/wiki/Quick_fixes

== Next steps ==
* address/fix any uncovered issues and concerns
* clean up wiki pages with tasks
* figure out the process when a task is OK to use without voting (direct
save, without the two person agreement)

== Moonshot goal ==
Mobile site/app that would bring up yes/no and multiple choice questions
from multiple tasks for the user's location. While I would love to do this,
lets discuss it in a separate thread if desired, as it is too far off at
this point.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yuri Astrakhan]

TLDR; Please read my previous email, and lets discuss the actual tool, its
capabilities, and how it can fit and add value to OSM ecosystem, while
minimizing potential negatives.

Frederik, I have offered to have a direct video conversation with you to
better understand your concerns, explain my goals, and bring it back into
productive scope, but no luck yet. I still hope you are more interested in
resolving our differences than having a public tribune.  Lets not spend
hours on emails, but try to understand each other's concerns in a private
conversation, without involving the entire world.  I am sure what you think
I am trying to do is substantially different from what I actually am trying
to do, and my understanding of your concerns is also different from your
actual concerns.

If there is a large group of people who are trying to do something
different from your strongly held believes, it means they have a problem
you might not be aware about. In your example, "kick foreigners out" is a
symptom of a problem - possibly related to people's insecurity or lack of
education. Vilifying them and calling their ideas outrageous makes us feel
righteous and united, but does not solve the actual problem or changes what
they think - it actually exacerbates it, because both sides become more
entrenched in their believes.

So yes, I do want to keep our conversation constructive (not positive!) -
understand concerns on all sides, and provide the most value to everyone
involved.


On Tue, Nov 7, 2017 at 2:57 AM, Frederik Ramm <frede...@remote.org> wrote:

> Hi,
>
> On 07.11.2017 07:29, Yuri Astrakhan wrote:
> > Please keep discussion to constructive suggestions and ideas - they help
> > us all move forward and reach agreement.
>
> I have a general remark about statements like the above, that is not
> related to your specific tool.
>
> Statements like this are aimed at silencing opposition. But that is
> neither fair, nor right, nor a good way for a community to move forward.
> Opposition must be allowed, and people who are in opposition must not be
> cast as "negative" (="bad").
>
> Just imagine if someone suggested something outrageous ("Let's deport
> all foreigners from or village") and then if someone says "no", they are
> told: "Please keep discussion to constructive suggestions and ideas".
> ("If you have a better idea on how to get rid of foreigners, we're all
> ears!")
>
> There are many ideas that are broken beyond repair, where the basic
> tenets are already so wrong that no constructive suggestion can ever
> make it good. Rejecting such ideas is good, and a valuable contribution.
>
> Please don't try to silence opposing voices by limiting discussion to
> "constructive suggestions".
>
> As I said, this is not aimed specifically at you; I think the last time
> I said it was in a discussion about a tree import where the importers
> asked critics to simply take their energy elsewhere instead of being
> "negative" about the import.
>
> 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 OSM Quick-Fix service

[Yuri Astrakhan]

JB, the "layer=0 removal" is one of the JOSM validations - it automatically
gets suggested to anyone editing an area with that object, with the "fix"
button autofixing it.  JOSM doesn't have a "mark this autofix as invalid"
button, which means that even if you don't autofix it, the next person
reviewing the same area may. This sounds identical to the issue raised by
Simon above:
> ...you don't actually "confirm" that something is a good edit or not. You
only have the choice of making an edit or leaving it to others to do. ...
This makes the whole thing entirely equivalent to a mechanical edit.

So we should either A) remove it from JOSM, or B) define when it should be
kept vs deleted, because otherwise we are not being consistent with
requirements.

In JOSM:
https://josm.openstreetmap.de/browser/josm/trunk/data/validator/unnecessary.mapcss?rev=12999#L6

On Thu, Nov 9, 2017 at 5:56 AM, JB <jb...@mailoo.org> wrote:

> Le 08/11/2017 à 19:43, Yuri Astrakhan a écrit :
>
>> removing layer=0
>>
> Please don't. Once again, mapping is done by humans, and layer=0 IS
> sometimes useful to humans, even if computers don't need it.
>
>
>
> ___
> 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 OSM Quick-Fix service

[Yuri Astrakhan]

On Thu, Nov 9, 2017 at 4:07 PM, ajt1...@gmail.com <ajt1...@gmail.com> wrote:

> On 09/11/2017 20:48, Yuri Astrakhan wrote:
>
>> JB, the "layer=0 removal" is one of the JOSM validations - it
>> automatically gets suggested to anyone editing an area with that object,
>> with the "fix" button autofixing it. JOSM doesn't have a "mark this autofix
>> as invalid" button, which means that even if you don't autofix it, the next
>> person reviewing the same area may. This sounds identical to the issue
>> raised by Simon above:
>> > ...you don't actually "confirm" that something is a good edit or not.
>> You only have the choice of making an edit or leaving it to others to do.
>> ... This makes the whole thing entirely equivalent to a mechanical edit.
>>
>> So we should either A) remove it from JOSM, or B) define when it should
>> be kept vs deleted, because otherwise we are not being consistent with
>> requirements.
>>
>>
> No, the two aren't equivalent.  In JOSM, validator suggestions are made
> after you've been editing in the area.  Typically where "default tags" such
> as "layer=0" (or "oneway=no" for that matter) are used are in places where
> something's an exception (maybe this is the only cross-town two-way street)
> , or there's more information to be mapped (maybe there's something yet to
> be mapped over or under the "layer=0" way that's obvious from the context
> of the data in the area).


Andy, "... obvious from the context of the data in the area" is the exact
problem.  It may be obvious to you, but another mapper who may visit the
same area might not be as experienced, and when they see a suggestion from
JOSM, it will be obvious to them to remove it. And if not them, than the
next person - making it equivalent to what Simon was saying - eventually
there will be a person who will overlook your obvious context and who will
heed to JOSM's advice.  It's just a matter of time.

  All you're doing is blindly performing (or encouraging the performance
> of) mechanical edits, where the mapper has no knowledge of the local area.
>
Incorrect, I am encouraging tagging experts, the same experts that decide
which tags should be used for what on the @tagging, to review just that
specific tag, case by case, and decide if the tag should be fixed, or if a
new rule should be made. Maybe the deprecation was a mistake, and there are
legit use cases?

>
> Ask yourself "in what way does removing layer=0 from a bunch of ways
> improve the quality of OpenStreetMap?".  It certainly adds no valid data.
> It could potentially remove information (if there's a problem with
> something else also tagged layer=0 nearby that will be obvious to a user of
> an interactive editor from context).
>

I strongly disagree, it greatly improves the quality of OSM, because it
simplifies the work that every data consumer has to do.  The layer=0 is a
tiny, perhaps less important subset of the big problem. If I am a data
consumer, I need to handle every case. and if something can be stored in
multiple ways, I need to handle all of them. And this increases my workload.

Fundamentally ,this is not about layer=0, but about all of the deprecated
tagging.  For example, natural=marsh → natural=wetland + wetland=marsh --
this implies that every data processor has to know both of these tagging
schemas.  And there are hundreds of others, with hundreds of thousands of
cases.

If I am a large organization, I have enough resources to handle each case
by my data team. So if OSM wants to cater to the deep pockets, leaving all
these deprecated tagging behind is fine. But if we want individuals and
small organizations to easily use the data without much effort, the data
must be as clean and straightforward as possible. Otherwise every single
data consumer has to redo the same work, and handle every corner case, or
it ends up ignoring or mishandling many of them.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yuri Astrakhan]

Thanks Mikel, very well put.

There are currently hundreds of deprecated features & JOSM validations,
with hundreds of thousands of instances. They seem to be good candidates
for community reviewing and fixing. Some of them have been there for over
10 years without being addressed. Setting up a bot to do them may cause
more problems than solving, but the Sophox tasks should help. Reviewing
each change one by one should help spot cases when the change should NOT
happen, and either be fixed manually, or the Sophox query needs changing.
Sophox tags each changset with a task ID, so it will be very easy to undo
in case of a wide-scale error.  This makes Sophox much safer than when
multiple types of changes are combined in the same changeset.

I have copied some of the JOSM & deprecation autofixes as Sophox tasks
(quick fixes page). Which of them would be good for the first review? It
should probably be more obvious, like replacing identical
maxspeed:forward+maxspeed:backward with maxspeed tag, or removing layer=0,
etc.

* https://wiki.openstreetmap.org/wiki/Quick_fixes

Thanks!

On Wed, Nov 8, 2017 at 10:35 AM, Mikel Maron <mikel.ma...@gmail.com> wrote:

> Hey everyone -- let's do stick to the topic at hand. My takeaways from the
> good points on the discussion here from Frederik and Yuri.
>
> * It's ok to have different points of view
> * Being respectful of each other is important. Very important
> * Let's not make disagreements personal
>
> Online communication is hard. We are missing all the context and cues from
> real life. Let's make an extra effort to get beyond the inevitable
> miscommunications when they crop up.
>
> -Mikel
>
> * Mikel Maron * +14152835207 <(415)%20283-5207> @mikel s:mikelmaron
>
>
> On Tuesday, November 7, 2017, 4:32:42 AM EST, Yuri Astrakhan <
> yuriastrak...@gmail.com> wrote:
>
>
> TLDR; Please read my previous email, and lets discuss the actual tool, its
> capabilities, and how it can fit and add value to OSM ecosystem, while
> minimizing potential negatives.
>
> Frederik, I have offered to have a direct video conversation with you to
> better understand your concerns, explain my goals, and bring it back into
> productive scope, but no luck yet. I still hope you are more interested in
> resolving our differences than having a public tribune.  Lets not spend
> hours on emails, but try to understand each other's concerns in a private
> conversation, without involving the entire world.  I am sure what you think
> I am trying to do is substantially different from what I actually am trying
> to do, and my understanding of your concerns is also different from your
> actual concerns.
>
> If there is a large group of people who are trying to do something
> different from your strongly held believes, it means they have a problem
> you might not be aware about. In your example, "kick foreigners out" is a
> symptom of a problem - possibly related to people's insecurity or lack of
> education. Vilifying them and calling their ideas outrageous makes us feel
> righteous and united, but does not solve the actual problem or changes what
> they think - it actually exacerbates it, because both sides become more
> entrenched in their believes.
>
> So yes, I do want to keep our conversation constructive (not positive!) -
> understand concerns on all sides, and provide the most value to everyone
> involved.
>
>
> On Tue, Nov 7, 2017 at 2:57 AM, Frederik Ramm <frede...@remote.org> wrote:
>
> Hi,
>
> On 07.11.2017 07:29, Yuri Astrakhan wrote:
> > Please keep discussion to constructive suggestions and ideas - they help
> > us all move forward and reach agreement.
>
> I have a general remark about statements like the above, that is not
> related to your specific tool.
>
> Statements like this are aimed at silencing opposition. But that is
> neither fair, nor right, nor a good way for a community to move forward.
> Opposition must be allowed, and people who are in opposition must not be
> cast as "negative" (="bad").
>
> Just imagine if someone suggested something outrageous ("Let's deport
> all foreigners from or village") and then if someone says "no", they are
> told: "Please keep discussion to constructive suggestions and ideas".
> ("If you have a better idea on how to get rid of foreigners, we're all
> ears!")
>
> There are many ideas that are broken beyond repair, where the basic
> tenets are already so wrong that no constructive suggestion can ever
> make it good. Rejecting such ideas is good, and a valuable contribution.
>
> Please don't try to silence opposing voices by limiting discussion to
> "constructive suggestions".
>

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Yuri Astrakhan]

On Tue, Oct 24, 2017 at 11:19 AM, Tomas Straupis 
wrote:

> 2017-10-24 15:56 GMT+03:00 Ryszard Mikke wrote:
> > Why, in this case is it better to have Wikipedia links in OSM point to
> > disambiguation page instead of link Hillfort 1 in OSM to Hillfort 1 in
> > Wikipedia, link Hillfort 2 accordingly and fix Wikipedia doubts in
> > Wikipedia?
>
>   So that the case is not forgotten and fixed properly (i.e. ALL tags
> fixed) by people who know how to do it, not by those who are doing
> guesswork and just silencing the "qa" script.

  But in general all automated guess-edits are reverted for the time
> being because it was clearly stated they are unhelpful and so
> unwanted.
>

Tomas, I do agree that there should not be an automatic script setting tags
based on a heuristic. But what you are saying is very strange if I
understood you correctly.  What I read here is that the only people allowed
to fix things are those that know ALL tags and their meaning.  This goes
counter to the common sense (nobody knows all 65000+ tags), and counter to
the existing warnings, such as JOSM's validator "when in doubt, ignore
them".  You can never have a person who knows everything about both - the
place and OSM tags.

There are two axis of editing:  local knowledge and OSM knowledge. They are
orthogonal - I could be a tagging expert, but not know the area, or a
novice editor with the expert local knowledge.  Additionally, "local
knowledge" very rapidly decays as you move away from where you live -
another street, neighborhood, city, state, country, continent.  If I see a
problem, I can reasonably research the topic, gain knowledge, and fix the
problems in my area of expertise. Of course someone who lives in the
incorrectly tagged building, and happens to be an expert OSM editor would
be ideal, but sorry, no such luck.

In most cases, the editors who decide to help will make data better. It
might not be perfect, but it is better than before.  When you say you will
revert things despite making data worse, just because you disagree with HOW
the problem was found, and not on the basis of decreasing data quality, you
go against the very idea of a common sense.

There is only one reasonable approach to editing - data should be in a
better shape after you than before.  More accurate. More complete.  Please
don't make assumptions that the data has gotten worse just because you
disagree that there should be a qa script - after all, you are using them
yourself, and no one is reverting all your work based on that.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yuri Astrakhan]

Ryszard, I have disabled the fixing from the "embed" mode - you can still
open the query (using "edit query"), click the "run" button (blue play
button), and fix things from there.

In my spare time, I am still working on the next version, based on all the
useful feedback:
* It will be easy to find the changes made for a specific task, and review
or revert them.
* It will be possible to "vote" on a change for an experimental task.
E.g., unless the task is marked as safe, two people will have to agree on a
change before it happens, assuming there are no "no" votes.
* It will be possible to have multiple choice tasks.
* multiple changes for the same task can go into the same changeset
* All votes will be stored in the same RDF database, making it possible to
use vote information in tasks.

I will write up a bit more about this project in a bit.  I think there was
a number of misconceptions about it, namely that it only relates to
Wikidata, and that its a bot rather than a platform for the community to
create and review tasks.

On Tue, Oct 24, 2017 at 8:04 AM, Ryszard Mikke <ryszard.mi...@gmail.com>
wrote:

> Even without disabling - what a better tool fixes, JOSM's autofix won't
> find...
>
> On 17 October 2017 at 09:50, Yuri Astrakhan <yuriastrak...@gmail.com>
> wrote:
>
>> Well, you kind of can fix one with the other - by introducing a better
>> tool and disabling some of the autofixes in JOSM (very easy to do).  A more
>> complex approach would clearly require a separate topic(s) and a
>> substantial dev involvement.
>>
>> P.S. No, https://master.apis.dev.openstreetmap.org/ doesn't have any
>> real data (it shows maps from live servers, but editing shows just a few
>> objects).
>>
>> On Tue, Oct 17, 2017 at 3:36 AM, Tobias Zwick <o...@westnordost.de> wrote:
>>
>>> I get your point, especially regarding the appliance of the JOSM
>>> fix-button as a "by-the-way" fixing.
>>>
>>> Though, you can't fix possible issues with of one tool by introducing
>>> another tool. People will not stop using (that feature of) JOSM. That is
>>> why I think, if you think you detected a problematic issue there in that
>>> editor, it should be discussed in a separate topic.
>>>
>>> On 17/10/2017 00:57, Yuri Astrakhan wrote:
>>> > Michael, I can only judge by my own experience adding validation
>>> autofix
>>> > rules - I added a number of Wikipedia tag auto cleanups to JOSM, and
>>> > they were reviewed by one or two JOSM developers and merged, probably
>>> > because they were deemed benign.  I don't know about the other rules,
>>> > but I suspect many of them also went this route.  Should have they been
>>> > discussed more widely? I don't know, but that question is complicated,
>>> > just like "what is a local community?" question. What a few devs may
>>> see
>>> > as benign, others may say needs a discussion, right?
>>> >
>>> > Mass editing is a different matter.  We consider mass editing when one
>>> > person goes out to fix something everywhere in the world.  But when we
>>> > provide a tool that automatically fixes something that you are looking
>>> > at, we don't view it as such.  Or at least we don't view it when it
>>> > happens as part of JOSM, but we do when it happens in my new tool. Of
>>> > course there is an important difference - JOSM doesn't guide you
>>> towards
>>> > those cases.
>>> >
>>> > I think massive "by-the-way" fixing is far worse than the targeted fix
>>> > of a single issue.
>>> >
>>> > When you want to fix a single issue in many places, you become a
>>> subject
>>> > matter expert.  You know all about that change, how it interacts with
>>> > other tags, what to watch out for, how to handle bad values, etc.  For
>>> > example, when fixing wikipedia tags, you would see the types of
>>> mistakes
>>> > people make, wrong prefixes people use, incorrect url encodings, hash
>>> > tags in urls, incorrect multiple values, ... .When you simply click
>>> > "fix" because JOSM validator tells you it can fix it automatically, you
>>> > don't have that knowledge, so it effectively becomes a distributed
>>> > mechanical edit without the "reject" capability.  My tool tries to
>>> > address this - to build domain experts in a narrow field, and let those
>>> > experts review changes one by one. I do not discount the value o

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Yuri Astrakhan]

Roland, thanks for the links. Local knowledge is very important, but lets
not make it into a sacred cow at the cost of common sense.  I have not been
to every single street in New York City. I am nearly 100% sure that all
editors has edited objects that were near their location, but that they
have not actually visited, or walked by without walking in, etc.  Local
knowledge is an important concept, but its physically impossible to walk
into every building and research every tag for every building.  Or are you
saying Tomas has visited every single street/building in Lithuania?

Also, local knowledge doesn't trump tagging standards - if I start tagging
national highways as power lines simply because I happened to be in the
area, it does not mean I am right -- more likely it means I am a novice
editor that should be helped by anyone - even if they are on the other side
of the planet.

My reading of Tomas answer is not that the Wikipedia tag was not fixed, or
that it can't be fixed, but that it should be left untouched because it
should be fixed in a perfect way only by a local, with all other tags too,
and it is better to have completely wrong tags than to have good tags but
other tags in less than perfect state. This is not local knowledge, this is
an editing preference, and a strange one at that.  Local knowledge needs to
coexist with OSM as a global movement, so I do hope this is not a turf war,
but rather a misunderstand that can be easily solved by reason.

On Wed, Oct 25, 2017 at 1:08 AM, Roland Olbricht 
wrote:

> But what you are saying is very strange if I understood you correctly.
>> What I read here is that the only people allowed to fix things are those
>> that know ALL tags and their meaning.
>>
>
> See https://wiki.openstreetmap.org/wiki/Welcome_to_Wikipedia_use
> rs#Original_research_always_wins
>
> Or similar statements on
> https://wiki.openstreetmap.org/wiki/Getting_Involved#Working_on_the_map
> https://wiki.openstreetmap.org/wiki/Good_practice#Map_what.
> 27s_on_the_ground
> https://wiki.openstreetmap.org/wiki/Disputes#On_the_Ground_Rule
>
> It is the local knowledge that matters. Tomas does know what it looks like
> there, and deems the wikipedia link correct. This is in line with similar
> cases like the mentioned distinction Aldi Nord/Aldi Süd and other.
>
> We expect you to assure that the tool is used only (or almost only) in
> cases where the user has local knowledge, i.e. has been there, physically,
> in person. Otherwise the tool is considered a disguised bot, no matter how
> it is dressed.
>
> Best regards,
>
> Roland
>
>
> ___
> 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] Local knowledge (was: Could we just pause any wikidata edits for a month or two?)

[Yuri Astrakhan]

>
> On 25.10.2017 08:22, Tomas Straupis wrote:
> > Yuri later tried to change the whole theme from "osm-wikidata-sql
> > tool" to "new general qa tool" in the same thread.
>
> And now into "is local knowledge really always necessary". I'm sure
> before too long Yuri will be starting to discuss whether what we see is
> really there, or perhaps just an imagination, and explain to us that we
> can't prove either way.
>

Frederik, I think you once again try to do a personal stab instead of
discussing the issue. Fighting imaginary targets is always better than
address real concerns, especially considering that Tomas statement above is
incorrect.

>
> The answer to the "local knowledge" issue is this: Local knowledge comes
> in shades. Someone who hasn't been to a particular street but lives in
> the same city can certainly make a better guess about things than
> someone who lives in the same country but in another city; and that
> person's assessment about something will still be better than that of a
> third person who doesn't speak the language and lives a continent away.
>

No argument here - I have been saying exactly the same thing - the further
it is from you, the less you may know about it.

>
> Local knowledge nearly always beats "common sense" applied by someone
> from far away. The person from far away *might* change "Thomas Eddison
> Street" to "Thomas Edison Street" based on general knowledge, but then
> if the local person says "no, it really says Eddison on the street sign"
> then that's what it is.
>
> Bad analogy. Fixing street names is clearly the most well known to the
local person, and noone would argue with that. It would be a bad idea to
fix street names across the globe, because yes, you are likely to make a
mistake. On the other hand, seeing that a Wikipedia link in Czech Republic
starts with cz: is an error. It can be easily fixed by someone who is an
expert in Wikipedia tags, but might be overlooked by someone with the local
knowledge.

But even in the absence of a particular objection from someone local,
> many in OSM take a dim view of "gardening" in areas where you don't even
> know the language or culture. It is much too easy to make mistakes.
>

I think this is a very broad statement. Knowing language and culture
obviously matters with tags like names, but may have very little to do with
others tags like the above cz: instead of cs: wikipedia tags.  Moreover, I
would argue that for *some* tags it is better to let global tagging expert
guide the process, instead of a novice with the local knowledge. In short,
do not pile together all types of tags - some are highly local, some
benefit from the global expertise.  All for a simple reason - every data
consumer needs to make sense of our data, so if we don't do grooming, every
single data consumer has to support every kind of obsolete tagging scheme
that was ever used. There are over 100 such autofixes in JOSM alone - do
you want every data consumer to be an expert in each one of them? I think
that goes against the main idea of OSM - free, easy to use data for map
projects.  Imagine someone who wants to do disaster aid app all of a sudden
has to dig through hundreds of not-yet-cleaned-up obsolete tagging rules,
simply because noone in that area happened to work on it yet.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Yuri Astrakhan]

On Wed, Oct 25, 2017 at 2:22 AM, Tomas Straupis 
wrote:
>
>   Yuri later tried to change the whole theme from "osm-wikidata-sql
> tool" to "new general qa tool" in the same thread. This change gives a
> lot of confusion on what are we really talking about. Only when
> talking about automated adding of wikidata or changing other tags
> based on wikidata I am strongly opposing and doing reverts. I'm
> strongly in favour of automated checking, comparing etc. - we've done
> a number (~40) of Lithuania specific rules starting with addressing
> information and up to topological rule checking.
>

Tomas, I must be blind, or you must be confused. Where have I spoken about
the "osm-wikidata-sql tool"?  I think you have mixed up a few threads...  I
did create a QA tool that quickly spot tens of thousands of errors. And
using it as a base, I also created a different tool for quick fixes (which
is not related to Wikidata, despite sharing the code). But neither were
mentioned in this thread from what I can see in the history. I know which
hunt could be a fun activity, but lets not do that. (i'm still in shock
over Malawi's vampire scare with many people dead. Sorry for side comment)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Yuri Astrakhan]

>
> Well, certainly Wikipedia links should only be added by people who know
> something about the feature in question, and not by a machine that
> compares name tags to Wikipedia entries and takes a wild guess.
>

I think this is a straw man argument - I don't think anyone is proposing to
add tags automatically based on a heuristics - like the name matching.
There are two things -  One is a tool that may suggest a match based on
some heuristic, but let human decide and pick the best option, or say that
this is incorrect. There is no "adding by a machine" here.  I think Mapbox
was building a tool like that.

The other portion is what has been happening - an automated addition of
wikidata based on existing wikipedia tag.  This was done automatically by
iD editor every time someone added Wikipedia link.  And it was also done by
me for the older objects. While this was clearly an automated process, it
was not a guess work based on name (discussed in another thread).  I
haven't been doing it for 1.5 months, iD has been doing it all this time
without any substantial problems uncovered.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Name:* tags in the local language

[Yuri Astrakhan]

Janko, while I agree that it is possible in theory, I am not sure this is a
big problem. After all, if you are downloading a single region, you are
much more likely to know more about that region, and not need any
defaults.  The problem solved by the default_language is fairly specific to
planet-level maps, where there are too many languages to manage
realistically.   I think that adding and managing this tag on every
possible region (tens of thousands?), just in case someone somewhere might
need it seems like a bad idea. Appending it dynamically on download might
be ok, but again - there has to be someone whom this benefit in a
significant way, and this has to be a simpler solution than alternatives.

One option BTW might be to create a service that produces a map of defaults
- than it would be a relatively small download, allowing users to convert
any geopoint into a language.


On Sat, May 5, 2018 at 2:25 AM Janko Mihelić <jan...@gmail.com> wrote:

> sub, 5. svi 2018. u 00:18 Yuri Astrakhan <yuriastrak...@gmail.com>
> napisao je:
>
>>
>> Tag description:
>> https://wiki.openstreetmap.org/wiki/Key:default_language
>>
>
> I like it overall. I'm not sure about this one:
> *Do not set it on any smaller sub-regions unless their default language is
> different.*
>
> I agree that is cleaner, but what if a data consumer only downloads one US
> state, how will it know the default language? Maybe there are some other
> ways I'm not aware of, like filling in the gaps in data before publishing
> derived maps.
>
> If this is indeed a problem for data consumers, I would set the tag on all
> subregions up until a sensible level. We can see the smallest size of a
> region some applications offer for download.
>
> Janko
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Name:* tags in the local language

[Yuri Astrakhan]

I have set this value on some of the more obvious cases in N & S Americas.
I have also created a wiki page describing the tag. Any help with this is
greatly appreciated, especially if you have local knowledge about
subregions!

Tag description:
https://wiki.openstreetmap.org/wiki/Key:default_language

P.S. Janko, please take a look at the single vs multiple languages per
region in that wiki page.  Does that make sense?


On Wed, May 2, 2018 at 1:01 PM Janko Mihelić <jan...@gmail.com> wrote:

> pon, 30. tra 2018. u 08:28 Yuri Astrakhan <yuriastrak...@gmail.com>
> napisao je:
>
>>
>> "official_language" is not a good tag name because it does not match the
>> meaning, e.g. the official languages of Canada are both en & fr, but
>> "name"
>> tag is always in English except for Quebec, where it is in French.
>>
>
>  I agree that "official_language" has a much too restrictive meaning. It
> will bury us in bureaucracy of "what is actually official".
> "default_language" is a bit vague, but maybe a better fit to solve this
> problem.
>
> So just look at a region, see in what language >90% of the labels are, and
> add default_language=*. It's not going to be 100% accurate, but infinitely
> better then nothing. Than try to get closer to 100% by adding
> default_language to subregions, and in the end, individual objects.
>
> I like that approach.
>
> Janko
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and new Wikipedia map features

[Yuri Astrakhan]

Mateusz, rendering still happens on the server right before being sent to
the client, but it COULD be rendered on the client too, because the
vector.pbf tiles could be accessed directly, bypassing the server side
rendering.

On Sat, May 5, 2018 at 3:01 PM Mateusz Konieczny <matkoni...@tutanota.com>
wrote:

>
> Thanks, I forgot/missed that rendering happens on
> client computer and vector tiles with all languages are cached.
>
> I also now have one more project on my list - look how
> vector tiles served by Wikipedia servers may be used
> (usage limits and what kind of data is provided).
>
> 4. May 2018 10:14 by yuriastrak...@gmail.com:
>
> Btw, this is already possible - Wikipedia servers let you access both
> images and raw vector tiles, so if someone wants to do the client part, it
> shouldn't be too hard.
>
> On Fri, May 4, 2018, 11:11 Yuri Astrakhan <yuriastrak...@gmail.com> wrote:
>
>> In reality, it is not impossible, or even that hard. If the vector tile
>> is sent to the client, than the client can decide which language to render
>> based on user preference.  The exact same code (it's all in JavaScript) can
>> be used to decide the labeling. Caching would only improve, because instead
>> of caching multiple raster tiles, it would only cache a single vector tile.
>>
>>  Mapbox.gl or open layers can both do this fairly efficiently.
>>
>>
>>
>> On Fri, May 4, 2018, 10:54 Mateusz Konieczny <matkoni...@tutanota.com>
>> wrote:
>>
>>>
>>>
>>>
>>> 4. May 2018 07:36 by md...@xs4all.nl:
>>>
>>> On 2018-05-04 00:33, Joe Matazzoni wrote:
>>>
>>> No fallback is currently defined for Polish. We’ll be happy to
>>> change that if you can show community consensus.
>>>
>>>
>>> Community consensus? You mean a bunch of people who decide for the whole
>>> country (many of them have no idea of the mechanisms behind it) what the
>>> strategy is?
>>> I'm sorry to say, but that can not be consensus. This needs to be able
>>> to be configured at user level.
>>>
>>>
>>> Server resources are not infinite, separate map cache for every user
>>> would be probably unfeasible.
>>> ___
>>> 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] OSM and new Wikipedia map features

[Yuri Astrakhan]

In reality, it is not impossible, or even that hard. If the vector tile is
sent to the client, than the client can decide which language to render
based on user preference.  The exact same code (it's all in JavaScript) can
be used to decide the labeling. Caching would only improve, because instead
of caching multiple raster tiles, it would only cache a single vector tile.

 Mapbox.gl or open layers can both do this fairly efficiently.



On Fri, May 4, 2018, 10:54 Mateusz Konieczny 
wrote:

>
>
>
> 4. May 2018 07:36 by md...@xs4all.nl:
>
> On 2018-05-04 00:33, Joe Matazzoni wrote:
>
> No fallback is currently defined for Polish. We’ll be happy to
> change that if you can show community consensus.
>
>
> Community consensus? You mean a bunch of people who decide for the whole
> country (many of them have no idea of the mechanisms behind it) what the
> strategy is?
> I'm sorry to say, but that can not be consensus. This needs to be able to
> be configured at user level.
>
>
> Server resources are not infinite, separate map cache for every user would
> be probably unfeasible.
> ___
> 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] Local language help

[Yuri Astrakhan]

Daniel, I agree - it seems most of the low-zoom Moroccan names are in a
triple-form,  and many local names are in a wild mix of french only and
multi-lingual ones:   https://overpass-turbo.eu/s/yE5 (thx trigpoint &
FredrikLindseth on IRC!)  Do you want to change it, or should I?

Also, there are still about 60 countries without a tag:
http://tinyurl.com/y9382ewv


On Tue, May 8, 2018 at 10:59 PM Daniel Koć <daniel@koć.pl> wrote:

> W dniu 08.05.2018 o 21:31, Yuri Astrakhan pisze:
>
> > This query shows a list of regions that have the new default_language
> > tag (you can multisort column with shift or control clicking the
> > headers).  http://tinyurl.com/yd6bx6s3
>
> What about places like Morocco? Shouldn't it be rather similar to
> Belgium - "fr ber ar" (because the name is "Maroc ⵍⵎⵖⵔⵉⴱ المغرب") than
> just "ar"?
>
> --
> "My method is uncertain/ It's a mess but it's working" [F. Apple]
>
>
> ___
> 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] Local language help

[Yuri Astrakhan]

Thanks to many people who have helped with this effort!

This query shows a list of regions that have the new default_language tag
(you can multisort column with shift or control clicking the headers).
http://tinyurl.com/yd6bx6s3

This query has also been added to the key:default_language wiki page at the
bottom.

P.S. same query, but with the last editing user included:
http://tinyurl.com/yatfd9sr

On Tue, May 8, 2018 at 12:02 AM Yuri Astrakhan <yuriastrak...@gmail.com>
wrote:

> Hi, most countries now have a default_language [1] tag, specifying the
> most likely language of the "name" tag in that region.  Here's a list of
> 60+ countries that have multiple official languages.  If you have local
> knowledge, or can research it, could you add the proper default_language
> tag to these relations?  Also, if most of the country uses one language,
> but some region uses a different default language, please set first
> language on the whole country, and the second language on the smaller admin
> region.  Do not set multiple languages, e.g.  "en;fr".  See
> Key:default_language wiki page.
>
> This query generates a list of admin boundary relations that have no
> default_language tag. It also shows country's the official languages per
> Wikidata.http://tinyurl.com/y9382ewv
>
> Wiki page:
> [1] https://wiki.openstreetmap.org/wiki/Key:default_language
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Local language help

[Yuri Astrakhan]

Hi, most countries now have a default_language [1] tag, specifying the most
likely language of the "name" tag in that region.  Here's a list of 60+
countries that have multiple official languages.  If you have local
knowledge, or can research it, could you add the proper default_language
tag to these relations?  Also, if most of the country uses one language,
but some region uses a different default language, please set first
language on the whole country, and the second language on the smaller admin
region.  Do not set multiple languages, e.g.  "en;fr".  See
Key:default_language wiki page.

This query generates a list of admin boundary relations that have no
default_language tag. It also shows country's the official languages per
Wikidata.http://tinyurl.com/y9382ewv

Wiki page:
[1] https://wiki.openstreetmap.org/wiki/Key:default_language
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Local language help

[Yuri Astrakhan]

Polyglot, thanks!  I just ran the list of names for Belgium -
http://overpass-turbo.eu/s/yEj (takes a few minutes and 20MB download).  It
seems that most of the names are single language.  Even cities tend to be a
single language strings, with a few exceptions (e.g. Brussels itself, and
the country name).

So on one hand, we could set default_language to "nl / fr / de" to match
the country name format, or to two languages that match "Bruxelles -
Brussel"  ("fr - nl" ?). But in reality, the most helpful value is just a
single "nl" or "fr" (?), because for almost all "name" tags, there is just
a single language. The country name is a very rare exception, but it has
many other name:xx defined anyway, so it is not a problem - if user
requests "fr" or "nl", there is a name:fr and name:nl. And if user requests
something that's not defined, at the end it will still fall back to name
tag.

What do you think?

On Wed, May 9, 2018 at 2:39 AM Jo <winfi...@gmail.com> wrote:

> Since there is not 1 language for Belgium and nl;fr;de is not allowed, it
> won't be possible to set this tag for Belgium. I did set it on the
> regions/communities.
>
> Polyglot
>
> 2018-05-08 22:31 GMT+02:00 Yuri Astrakhan <yuriastrak...@gmail.com>:
>
>> Daniel, I agree - it seems most of the low-zoom Moroccan names are in a
>> triple-form,  and many local names are in a wild mix of french only and
>> multi-lingual ones:   https://overpass-turbo.eu/s/yE5 (thx trigpoint &
>> FredrikLindseth on IRC!)  Do you want to change it, or should I?
>>
>> Also, there are still about 60 countries without a tag:
>> http://tinyurl.com/y9382ewv
>>
>>
>> On Tue, May 8, 2018 at 10:59 PM Daniel Koć <daniel@koć.pl> wrote:
>>
>>> W dniu 08.05.2018 o 21:31, Yuri Astrakhan pisze:
>>>
>>> > This query shows a list of regions that have the new default_language
>>> > tag (you can multisort column with shift or control clicking the
>>> > headers).  http://tinyurl.com/yd6bx6s3
>>>
>>> What about places like Morocco? Shouldn't it be rather similar to
>>> Belgium - "fr ber ar" (because the name is "Maroc ⵍⵎⵖⵔⵉⴱ المغرب") than
>>> just "ar"?
>>>
>>> --
>>> "My method is uncertain/ It's a mess but it's working" [F. Apple]
>>>
>>>
>>> ___
>>> 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] Local language help

[Yuri Astrakhan]

Martin, in the "fr - nl" value, the "" separator is
what is being used in the name tag itself. I don't think it is very common
to have all three characters in the name, other than to split multiple
languages. In the few rare cases when it does happen, it would be enough to
also add "name:fr" and "name:nl" tags to fix the issue -- localization
would take the specific language, and won't even try to parse the name
tag.  I think finding these cases should be relatively easy with OT.

On Thu, May 10, 2018 at 1:01 AM Martin Koppenhoefer <dieterdre...@gmail.com>
wrote:

>
>
> sent from a phone
>
> On 9. May 2018, at 02:37, Yuri Astrakhan <yuriastrak...@gmail.com> wrote:
>
> or to two languages that match "Bruxelles - Brussel"  ("fr - nl" ?).
>
>
>
> The hyphen/dash  is not a good choice for separating multiple languages
> because it occasionally occurs in names, e.g.
> https://en.m.wikipedia.org/wiki/Castrop-Rauxel
> https://en.m.wikipedia.org/wiki/Dessau-Roßlau
> etc.
>
> Not sure about the slash (it sometimes occurs in German short names, e.g.
> Frankfurt/Main, Frankfurt/Oder), but it seems a tad better.
>
> Cheers,
> Martin
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Local language help

[Yuri Astrakhan]

Martin, how can we evaluate the extent of this, to see how serious this may
be?

BTW, I totally agree that doing a guessing game based on "nl - fr" to parse
the name is much worse than simply picking "name:nl" or "name:fr" when they
are available. names with multiple languages are not very helpful for the
truly multilingual maps.

On Thu, May 10, 2018 at 2:10 AM Martin Koppenhoefer <dieterdre...@gmail.com>
wrote:

>
>
> sent from a phone
>
> > On 10. May 2018, at 00:47, Yuri Astrakhan <yuriastrak...@gmail.com>
> wrote:
> >
> > In the few rare cases when it does happen, it would be enough to also
> add "name:fr" and "name:nl" tags to fix the issue -- localization would
> take the specific language, and won't even try to parse the name tag.  I
> think finding these cases should be relatively easy with OT.
>
>
> The problem I see with less prominent objects is that you only have a name
> and can’t tell whether that is one name in one language or 2 names in
> different languages for the same thing separated by a hyphen. Potentially
> this could happen in other tags like operator as well.
>
> cheers,
> Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Local language help

[Yuri Astrakhan]

Jo, thx, so if these kinds of objects already have "name:xx" for all
mentioned languages, international map would use those instead of the name
tag anyway, so that's not an issue.

BTW, international maps have launched on Wikipedias!
https://lists.wikimedia.org/pipermail/wikitech-l/2018-May/089964.html

On Thu, May 10, 2018 at 2:34 AM Jo <winfi...@gmail.com> wrote:

> Where problems actually do occur is in streets which have a different name
> on both sides (only in Belgium, I guess. It happens on streets that form
> the border between two 'villages'). Anyway, then the name tag can contain
> up to 4 variants.
>
> The separator is ' - ' on purpose, to distinguish it from a simple hyphen.
> We were smart enough not to use that ' - ' combination for anything else
> than separating 2 language forms. And there is always a name:nl and name:fr
> to compare with on those objects.
>
> Jo
>
> 2018-05-10 1:10 GMT+02:00 Martin Koppenhoefer <dieterdre...@gmail.com>:
>
>>
>>
>> sent from a phone
>>
>> > On 10. May 2018, at 00:47, Yuri Astrakhan <yuriastrak...@gmail.com>
>> wrote:
>> >
>> > In the few rare cases when it does happen, it would be enough to also
>> add "name:fr" and "name:nl" tags to fix the issue -- localization would
>> take the specific language, and won't even try to parse the name tag.  I
>> think finding these cases should be relatively easy with OT.
>>
>>
>> The problem I see with less prominent objects is that you only have a
>> name and can’t tell whether that is one name in one language or 2 names in
>> different languages for the same thing separated by a hyphen. Potentially
>> this could happen in other tags like operator as well.
>>
>> cheers,
>> Martin
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Local language help

[Yuri Astrakhan]

Jo, thx. I just looked at all names inside relation 54094
(Brussels-Capital) - 12.691 names without the " - ", and 22,655 with them,
so makes perfect sense, thanks!   I think it doesn't really matter if
default_language is set for the whole Belgium to any specific language, or
left undefined, because the region with the higher admin_level, or a
non-admin smaller region would overwrite it anyway. Thanks for the
explanation!

On Wed, May 9, 2018 at 8:46 AM Jo <winfi...@gmail.com> wrote:

> The whole country has 3 official languages. In the north nl is the
> official language, in the south fr. And a small area in the east is de.
> Brussels is officially bilingual. Hence all names there will be a
> combination of fr - nl.
>
> Normally I would expect Belgium to not have default_language set. You may
> have to keep a list of countries where it only makes sense to look at the
> next smaller geographic regions.
>
> I expect the same goes for Switzerland (whole country 3-4 official
> languages, but at the next geographic level it is clear which language is
> spoken/official for which region).
>
> I think in most multilingual countries the regions are not so clearly
> defined.
>
> Jo
>
> 2018-05-09 2:37 GMT+02:00 Yuri Astrakhan <yuriastrak...@gmail.com>:
>
>> Polyglot, thanks!  I just ran the list of names for Belgium -
>> http://overpass-turbo.eu/s/yEj (takes a few minutes and 20MB download).
>> It seems that most of the names are single language.  Even cities tend to
>> be a single language strings, with a few exceptions (e.g. Brussels itself,
>> and the country name).
>>
>> So on one hand, we could set default_language to "nl / fr / de" to match
>> the country name format, or to two languages that match "Bruxelles -
>> Brussel"  ("fr - nl" ?). But in reality, the most helpful value is just a
>> single "nl" or "fr" (?), because for almost all "name" tags, there is just
>> a single language. The country name is a very rare exception, but it has
>> many other name:xx defined anyway, so it is not a problem - if user
>> requests "fr" or "nl", there is a name:fr and name:nl. And if user requests
>> something that's not defined, at the end it will still fall back to name
>> tag.
>>
>> What do you think?
>>
>> On Wed, May 9, 2018 at 2:39 AM Jo <winfi...@gmail.com> wrote:
>>
>>> Since there is not 1 language for Belgium and nl;fr;de is not allowed,
>>> it won't be possible to set this tag for Belgium. I did set it on the
>>> regions/communities.
>>>
>>> Polyglot
>>>
>>> 2018-05-08 22:31 GMT+02:00 Yuri Astrakhan <yuriastrak...@gmail.com>:
>>>
>>>> Daniel, I agree - it seems most of the low-zoom Moroccan names are in a
>>>> triple-form,  and many local names are in a wild mix of french only and
>>>> multi-lingual ones:   https://overpass-turbo.eu/s/yE5 (thx trigpoint &
>>>> FredrikLindseth on IRC!)  Do you want to change it, or should I?
>>>>
>>>> Also, there are still about 60 countries without a tag:
>>>> http://tinyurl.com/y9382ewv
>>>>
>>>>
>>>> On Tue, May 8, 2018 at 10:59 PM Daniel Koć <daniel@koć.pl> wrote:
>>>>
>>>>> W dniu 08.05.2018 o 21:31, Yuri Astrakhan pisze:
>>>>>
>>>>> > This query shows a list of regions that have the new default_language
>>>>> > tag (you can multisort column with shift or control clicking the
>>>>> > headers).  http://tinyurl.com/yd6bx6s3
>>>>>
>>>>> What about places like Morocco? Shouldn't it be rather similar to
>>>>> Belgium - "fr ber ar" (because the name is "Maroc ⵍⵎⵖⵔⵉⴱ المغرب") than
>>>>> just "ar"?
>>>>>
>>>>> --
>>>>> "My method is uncertain/ It's a mess but it's working" [F. Apple]
>>>>>
>>>>>
>>>>> ___
>>>>> 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] Local language help

[Yuri Astrakhan]

Marc, Oleksiy, thanks for your insights! And Marc, I agree that it should
always be up to the local community to decide.  The only thing I ask is to
please keep in mind that the "default_language" is simply a reflection of
what local OSM editors have already used for the name tag in the majority
of cases, and the reflection of the OSM naming rules in the area, not the
official language.

Eventually we could even get iD editor to show the language name next to
the "name" tag  (e.g.  "name in Dutch: []"), or possibly to auto-create
a corresponding name:nl=... tag (at least for the single language areas)

On Thu, May 10, 2018 at 12:55 PM Oleksiy Muzalyev <
oleksiy.muzal...@bluewin.ch> wrote:

> This was exactly my point. That it is a sensitive topic. And it may be
> unclear to people who live in a national state with a single official
> language.
> That is why I provided the texts of articles, to illustrate that there
> is a multi-language historical equilibrium reflected it the official
> documents.
> Best regards,
> Oleksiy
>
> On 10.05.18 11:35, Marc Gemis wrote:
> > Don't you think that Belgians like Jo and the rest of the Belgian
> > community know best what the default language is in a certain area ?
> > This can be a pretty sensitive topic, which is not always easy to
> > understand by outsiders. So please let the Belgian community decide
> > the default language without pointing us to our constitution.
> >
> >
> > regards
> >
> > m. (from Belgium)
> >
> >
> > p.s. Besides those areas you mention we also have Municipalities with
> > facilities [1]
> >
> >
> > [1]
> https://en.wikipedia.org/wiki/Municipalities_with_language_facilities
> >
> > On Thu, May 10, 2018 at 10:43 AM, Oleksiy Muzalyev
> >  wrote:
> >> On 09.05.18 07:46, Jo wrote:
> >>> The whole country has 3 official languages. In the north nl is the
> >>> official language, in the south fr. And a small area in the east is de.
> >>> Brussels is officially bilingual. Hence all names there will be a
> >>> combination of fr - nl.
> >>>
> >>> Normally I would expect Belgium to not have default_language set. You
> may
> >>> have to keep a list of countries where it only makes sense to look at
> the
> >>> next smaller geographic regions.
> >>>
> >>> I expect the same goes for Switzerland (whole country 3-4 official
> >>> languages, but at the next geographic level it is clear which language
> is
> >>> spoken/official for which region).
> >>>
> >>> I think in most multilingual countries the regions are not so clearly
> >>> defined.
> >>>
> >>> Jo
> >>
> >> Hello Jo and Yuri,
> >>
> >> Here is the text of the article 4 of the Belgian constitution [1]
> >>
> >> "Article 4
> >> Belgium comprises four linguistic regions: the Dutch-speaking region,
> the
> >> French-
> >> speaking region, the bilingual region of Brussels-Capital and the
> >> German-speaking region.
> >> Each municipality of the Kingdom forms part of one of these linguistic
> >> regions."
> >>
> >> In the Swiss constitution [2] it is stated directly that there are four
> >> national languages. It is also the article 4:
> >>
> >> "Art. 4 National languages
> >> The National Languages are German, French, Italian, and Romansh."
> >>
> >> It is not a light question, - which language is the default one for
> these
> >> countries. In my opinion, following these official texts is the best
> >> solution.
> >>
> >> [1]
> >>
> https://www.dekamer.be/kvvcr/pdf_sections/publications/constitution/GrondwetUK.pdf
> >> [2]
> >>
> https://www.admin.ch/opc/en/classified-compilation/19995395/index.html#a4
> >>
> >> Best regards,
> >> Oleksiy
> >>
> >>
> >> ___
> >> 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] OSM and new Wikipedia map features

[Yuri Astrakhan]

Btw, this is already possible - Wikipedia servers let you access both
images and raw vector tiles, so if someone wants to do the client part, it
shouldn't be too hard.

On Fri, May 4, 2018, 11:11 Yuri Astrakhan <yuriastrak...@gmail.com> wrote:

> In reality, it is not impossible, or even that hard. If the vector tile is
> sent to the client, than the client can decide which language to render
> based on user preference.  The exact same code (it's all in JavaScript) can
> be used to decide the labeling. Caching would only improve, because instead
> of caching multiple raster tiles, it would only cache a single vector tile.
>
>  Mapbox.gl or open layers can both do this fairly efficiently.
>
>
>
> On Fri, May 4, 2018, 10:54 Mateusz Konieczny <matkoni...@tutanota.com>
> wrote:
>
>>
>>
>>
>> 4. May 2018 07:36 by md...@xs4all.nl:
>>
>> On 2018-05-04 00:33, Joe Matazzoni wrote:
>>
>> No fallback is currently defined for Polish. We’ll be happy to
>> change that if you can show community consensus.
>>
>>
>> Community consensus? You mean a bunch of people who decide for the whole
>> country (many of them have no idea of the mechanisms behind it) what the
>> strategy is?
>> I'm sorry to say, but that can not be consensus. This needs to be able to
>> be configured at user level.
>>
>>
>> Server resources are not infinite, separate map cache for every user
>> would be probably unfeasible.
>> ___
>> 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] WMF: "Interactive maps, now in your language"

[Yuri Astrakhan]

* The BIG part of the announcement is that OSM data is now being used to
create truly multilingual map with a very large exposure.  I hope some
people here are not saying that such project should not have been built? If
you want to help, see at the end.
* I do not think names should be simply copied from WD into OSM - for many
of the reasons mentioned above, plus I am not a fan of duplicate data being
out of sync.
* I do believe Kartotherian (map service used by WMF) should use Wikidata
to augment names when missing in OSM.
* The fundamental problem is that WMF refuses to do any additional maps
work. Basically there was a star tech team put together for a few months to
address overwhelming community demand for better maps, rather than spending
resources on projects that community has very little interest in.  The team
delivered some of the hot-button things, but it was dissolved to work on
other things. In other words - things that are in high demand by community
are only worked on for a short time by a small team, and then forgotten by
WMF.  "sad."
* Naming is not a local expertise. Someone in Russia would know the Russian
name for New York better than someone who actually lives in New York, but
doesn't speak the language. That said, I would think at least some
languages have a relatively well defined algorithm to transliterate foreign
names?  And only if auto-transliteration fails, or if there is an
alternative well established spelling, it should be entered into OSM/WD.
Just thinking out loud here.
* I really hope this conversation can be productive, and oriented towards
solving issues, and not an unproductive and emotional blame game. I have
helped with the maps translation project, and while I can only speak about
the engineers I spoke with, everyone there made the best efforts to bring
first truly multilingual maps to the world. Of course not all the names
data is there, and there are multiple ways to fix that. So rather than
throwing  at each other, I do hope some volunteers would step up to 1)
guide WP community on improving name situation, and best approaches
according to OSM rules, 2) help with the development effort since WMF is
not interested, 3) help organize it all.  I could try to help with (2),
send me an email if interested.

On Fri, Jun 29, 2018 at 1:24 PM Mateusz Konieczny 
wrote:

>
> 29. Jun 2018 13:18 by a...@pigsonthewing.org.uk:
>
> On 29 June 2018 at 11:38, Max  wrote:
>
> "Add the missing names to OSM in your language."
>
> That is inflating the OSM database with something that Wikidata has solved
> already in a much better way. Why would someone from wikimedia recommend to
> create a less mentainable version of their database?
>
>
> Because the OSM community refuses to allow the import of data from
> Wikidata.
>
>
> Because WIkidata data is license-incompatible with OSM.
> ___
> 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] Name:* tags in the local language

[Yuri Astrakhan]

Multiple semicolon-separated values do not solve the main problem -
figuring out the language of the "name" tag. If a region uses one value in
the name tag, "default_language" should be set to just one language.

If the whole region uses "xx - yy" convention in the name tag,
default_language could be set to "xx - yy" -- allowing tools to parse
name tag into two languages (although this would be an error prone method).

"official_language" is not a good tag name because it does not match the
meaning, e.g. the official languages of Canada are both en & fr, but "name"
tag is always in English except for Quebec, where it is in French.

Are there any objections to this (fuzzy) approach? Should the tag be called
something else?

* Use the largest possible admin region to set the "default_language" tag
to a single language code.  "default_language"Z does not mean the official
language of the region. It only specifies the language of the "name" tag.
* A region may contain a sub-region with a different default_language.
* If a region uses mixed languages in all of its name tags, eg. "[name in
en] - [name in zh]", set default_language="en - zh".  Try to keep it to a
somewhat parsable value to help data consumers.
* In some rare cases, additional non-admin regions might be required for
the default_language.  Try to avoid it if possible.


On Thu, Apr 26, 2018 at 5:41 PM Daniel Koć  wrote:

> W dniu 26.04.2018 o 15:36, Martin Koppenhoefer pisze:
>
>
> 2018-04-26 14:16 GMT+02:00 Daniel Koć :
>
>>
>> Isn't it like this:
>>
>> Country Belgium - official_language=de;fr;nl
>> Region Brussels-Capital - official_language=fr;nl
>> City Eupen - official_language=de
>>
>> What would be wrong with this scheme?
>
>
>
> it is only about "official languages" and it would somehow imply we would
> not want names added through ground truth for cases where the language the
> name is in, would not be recognized as an official language.
>
>
> Sure, that's why I suggested common_language=* (common_language=xx +
> name:xx=* is just like saying "name=* is in xx").
>
> Could you explain this problem using some examples?
>
> I also don't know what this would imply for areas without formal
> government / disputed areas. Whose "official" language would we tag?
>
>
> That's interesting case. How do we tag the borders for such areas?
>
> If countries/regions with known official_language=* are overlapping, the
> language would be known for both and you have to choose one or show both
> (the same as official_language=xx;yy).
>
> Another solution would be to use some special values, like "none" or
> "disputed" for this area (unfortunately "no" is a code for Norwegian
> language).
>
> --
> "My method is uncertain/ It's a mess but it's working" [F. Apple]
>
> ___
> 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] OSM and new Wikipedia map features

[Yuri Astrakhan]

P.S. example - this library [1] might be a good fit (any other
suggestions?). It does universal transliteration, yet even the author
writes this:

"transliteration supports almost all common languages whereas there might
be quirks in some specific languages. For example, Kanji characters in
Japanese will be transliterated as Chinese Pinyin. I couldn't find a better
way to distinguish Chinese Hanzi and Japanese Kanji. So if you would like
to romanize Japanese Kanji, please consider kuroshiro."

[1]: https://www.npmjs.com/package/transliteration#caveats

On Fri, May 4, 2018 at 12:20 AM Yuri Astrakhan <yuriastrak...@gmail.com>
wrote:

> Christoph, I agree that this would be an awesome improvement, yet I think
> there is a problem to implement it. Most languages have their own
> transliteration rules, so transliterating "name" tag without the knowledge
> of its language will produce a lot of incorrect names.
>
> I have posted in another threads about this, proposing "default_language"
> tag to be added to the admin (or smaller) regions to solve this.  Copying
> the rules:
>
> * Use the largest possible admin region to set the "default_language" tag
> to a single language code.  "default_language" does not mean the official
> language of the region. It only specifies the language of the "name" tag.
> * A region may contain a sub-region with a different default_language.
> * If a region uses mixed languages in all of its name tags, eg. "[name in
> en] - [name in zh]", set default_language="en - zh".  Try to keep it to a
> somewhat parsable value to help data consumers.
> * In some rare cases, additional non-admin regions might be required for
> the default_language.  Try to avoid it if possible.
>
>
> On Fri, May 4, 2018 at 12:09 AM Christoph Hormann <o...@imagico.de> wrote:
>
>> On Thursday 03 May 2018, Joe Matazzoni wrote:
>> > [...]
>> >
>> > We don’t anticipate that these new maps will put any strain on OSM
>> > performance. The impact I do foresee—and hope for—is that the new
>> > exposure of multilingual map data will inspire many more Wikimedians
>> > to contribute to OSM. This is likely to happen when users start to
>> > see, as they will for the first time, that names in their language
>> > for some features and places are not available.
>>
>> The first and most fundamental thing you should do is add
>> automatic transliteration as a fallback for multilingual names.
>> Otherwise people will inevitably add tons of non-verifiable
>> transliterated names in a misguided attempt improve the map.
>>
>> --
>> Christoph Hormann
>> http://www.imagico.de/
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and new Wikipedia map features

[Yuri Astrakhan]

I cannot speak for WMF, only about the actual Kartotherian stack behind it,
and the way they are currently using it:

On Fri, May 4, 2018 at 12:52 AM Daniel Koć  wrote:

>
> 1. The localized maps lack fallback rules (I'm speaking of Polish
> language at least). I would ask for English as a fallback for maps in
> Polish, but I don't know where should it be requested or configured? Is
> this list the right place?:
>
> https://github.com/kartotherian/babel/blob/master/lib/fallbacks.json
>
> See also how the name tag is picked here:
https://github.com/kartotherian/babel/blob/master/lib/LanguagePicker.js#L106
It has went through several revisions recently, so this is somewhat in a
flux.

2. How many languages do you want to support in total and what hardware
> resources are needed for that using your toolchain?
>

Kartotherian itself can handle unlimited number of languages.  Vector tiles
can simply hold every possible language, and babel picks the one you want
based on the above heuristic.   My understanding is that currently WMF does
not filter out any languages, nor does it plan to, so any lang=xx would
work, where xx comes directly from the name:xx tags.


> 3. What about the same language using different scripts, do you plan to
> support them all?
>
> Babel does not actually know much about the "language". It looks at the
language codes, trying to match it to the fallbacks, and uses heuristic
when fallback fails.   E.g. it should be possible to simply have two
language codes for Serbian in Latin & Cyrillic, and say that if one is
available when the other is not, to fallback.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and new Wikipedia map features

[Yuri Astrakhan]

Christoph, I agree that this would be an awesome improvement, yet I think
there is a problem to implement it. Most languages have their own
transliteration rules, so transliterating "name" tag without the knowledge
of its language will produce a lot of incorrect names.

I have posted in another threads about this, proposing "default_language"
tag to be added to the admin (or smaller) regions to solve this.  Copying
the rules:

* Use the largest possible admin region to set the "default_language" tag
to a single language code.  "default_language" does not mean the official
language of the region. It only specifies the language of the "name" tag.
* A region may contain a sub-region with a different default_language.
* If a region uses mixed languages in all of its name tags, eg. "[name in
en] - [name in zh]", set default_language="en - zh".  Try to keep it to a
somewhat parsable value to help data consumers.
* In some rare cases, additional non-admin regions might be required for
the default_language.  Try to avoid it if possible.


On Fri, May 4, 2018 at 12:09 AM Christoph Hormann  wrote:

> On Thursday 03 May 2018, Joe Matazzoni wrote:
> > [...]
> >
> > We don’t anticipate that these new maps will put any strain on OSM
> > performance. The impact I do foresee—and hope for—is that the new
> > exposure of multilingual map data will inspire many more Wikimedians
> > to contribute to OSM. This is likely to happen when users start to
> > see, as they will for the first time, that names in their language
> > for some features and places are not available.
>
> The first and most fundamental thing you should do is add
> automatic transliteration as a fallback for multilingual names.
> Otherwise people will inevitably add tons of non-verifiable
> transliterated names in a misguided attempt improve the map.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and new Wikipedia map features

[Yuri Astrakhan]

Daniel, the only real difference between serving every available language
and serving just one is cache fragmentation, and that's may be different in
your case.

The vector tiles get pre-generated the same way, and they simply contain
all languages instead of one. Disk space wise, the difference is
inconsequential.

Kartotherian dynamically picks the language during the rendering. There is
some (not yet measured, but hopefully very small) performance penalty doing
dynamic language picking, but that should not be a big impact in case of a
good caching in front of the rendering.  I would recommend simply putting a
few Varnish boxes in front of your rendering servers if you are ok with the
maps being a bit stale.

On Fri, May 4, 2018 at 2:32 AM Daniel Koć  wrote:

> W dniu 04.05.2018 o 01:17, Joe Matazzoni pisze:
>
> > b) how many server resources do you need for rendering  languages
> > that you want to support (not the software stack used)?
> >
> > ?? Are you asking about OSM resources or WMF resources?
>
> I mean WMF resources.
>
> I'm asking because we want to have localized maps in OSM too and
> rendering just one (default) raster style eats most of the resources of
> 4 servers. This would not work for (let's say) 300 language versions, of
> course.
>
> We refresh default rendering in minutes usually, but even if we use more
> relaxed times for localized maps, it's still too much - with 1 language
> per day we would refresh them all once a year...
>
> We think about vector style migration lately, so it might help here, but
> I don't think this will work like 100x times faster.
>
> --
> "My method is uncertain/ It's a mess but it's working" [F. Apple]
>
>
>
> ___
> 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] OSM and new Wikipedia map features

[Yuri Astrakhan]

Daniel, sure, I can give you the full scoop. Considering that I designed
and developed most of it, I do have some knowledge here. Big kudos to Max
Semenik for developing all the initial data queries and php work, all the
amazing UI done by Julien Girault, and the current maps engineering team
for a lot of good recent work, especially the multilingual support.

Summary:
* OSM data is imported a postgres DB with osm2pgsql (initially used default
schema, now migrating to ClearTables)
* Tilerator (Kartohterian's tile generation manager) is used to generate
vector tiles from SQL queries. One of the SQL output fields is a
JSON-formatted value with all the available languages  --  {"en":'"...,"
"fr":"...", ...}.  Mapnik creates vector tiles from the SQL output, and
babel decodes them, expands languages into multiple fields, and
recompresses them. Tilerator then stores them into Cassandra database
(WMF), but you could use any other storage, e.g. postgress or mbtiles.  So
as the result, tilerator's pipeline produces vector tiles with all
available languages.  No rendering is done yet.   Tilerator generates just
the  z0..z14.  My guesstimate is ~300GB, but these numbers could have
changed. Sadly, tiles tiles are not as optimized as what Open Map Tiles
produce, hence slightly oversized.
* When user requests a tile in a given language, vector tile is loaded from
storage, modified on the fly by using babel - unpacks the tile and this
time choose just one language. The tile is repacked and passed to mapnik
for rendering. The resulting tile is not stored on disk, but it does get
cached by Varnish.

So as you can see, there is nearly no difference between one language and
unlimited number of languages with this approach - except for the slightly
slower generation and rendering, and bigger cache fragmentation.  See
various Kartotherian repos in github for more information.


-- Yuri  / @nyuriks

On Fri, May 4, 2018 at 4:14 AM Daniel Koć <daniel@koć.pl> wrote:

> W dniu 04.05.2018 o 02:30, Yuri Astrakhan pisze:
> > Daniel, the only real difference between serving every available
> > language and serving just one is cache fragmentation, and that's may
> > be different in your case.
>
> Sure, but you're talking about just one link of the chain. The WMF
> vector tiles are produced from a database, rasterized somewhere down the
> line, then probably written on the disk, served, cached etc, so it's not
> that simple.
>
> That's why I ask about the bottom line in this specific case. There are
> many factors which will be different (like how complex the style is, for
> example), but it's good to estimate the order of magnitude at least. But
> all the details are also interesting to me.
>
> --
> "My method is uncertain/ It's a mess but it's working" [F. Apple]
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM tagging validation lib

[Yuri Astrakhan]

Declarative rules are usually not very good. Every tool must understand
every type of rule, and must be updated when new rule types are introduced.
Plus declarative grammar is either too limiting, or eventually starts
looking like a scripting language itself, and we end up building an
execution environment in every tool.

I think a better path is executing scripts inside other languages, e.g.
* a JavaScript library ran by Java, Python, C++, ...
* a lib that gets compiled into a webassembly for browser, or connected to
other languages via native bindings (less tried path)

The lib would need an API to
* access local data state
* access master OSM DB for additional data
* access other tools like taginfo

Integrating scripting environment may be difficult, but offers far greater
benefits of rule consistency and flexibility.


On Sun, Dec 24, 2017 at 7:30 AM, Colin Smale  wrote:

> The technical differences between java and JS do not preclude generic
> thinking. Consider tzdata[1] for example, which does something analogous
> for time zone data.
>
> The "rules database" can be made portable, in the form of XML or JSON for
> example. The logic for using these rules can be described in a portable
> way. Then you add a set of compliance tests, and publish a reference
> implementation to demonstrate that is is possible to implement it. After
> that, the logic can be implemented in any language you like, checked
> against the compliance tests and the bindings published.
>
> Externalising the rules database enables updates and customisations for
> particular reasons. Depending on the specific use case and the associated
> non-functionals, validation could possibly be offered as a cloud service
> (not necessarily by OSM).
>
>
> //colin
>
> [1] https://en.wikipedia.org/wiki/Tz_database
>
> On 2017-12-24 12:18, James wrote:
>
> ID is javascript, JOSM is java. So right there I already see a
> intercompatibility issue
>
> On Dec 24, 2017 6:12 AM, "François Lacombe" 
> wrote:
>
>> Hi
>>
>> Here is an idea I got regarding tagging validation in editors (iD, JOSM,
>> others).
>> Subsequently to wiki proposal voting and cleanups, it's currently
>> necessarily to open issues in each editor repository to ask for new tagging
>> validation rules.
>>
>> It can sometimes be time consuming to develop those new rules and such a
>> work is done independently by each project maintainer. While each project
>> have its own specific components, background logic is the same.
>>
>> Would a new lib called like osmtagvalidator or so in charge of doing
>> conform validation to wiki be useful?
>> It may be shared by any project involved in osm editing and preserve its
>> resources for other valuable developments.
>>
>> For me, validation doesn't prevent users to use tags they want, but only
>> warn them about possible mistakes.
>>
>> How would devs and users feel about this?
>>
>> All the best
>>
>> François
>>
>> ___
>> 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
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM tagging validation lib

[Yuri Astrakhan]

Colin, I think we should look at JOSM's validations as a good example of
what is needed. For some validations, it extended MapCSS with its own
custom quirks, and even added its own unit testing. For other types of
validations (e.g. geometries), it seems to fall back to full code.  Having
a single language to express any types of validation would simplify
maintenance and participation.

I don't think people should translate the JS reference implementation at
all. That recreates the problem we have now. Instead, all tools should use
one common library directly. The only problem is integration - Java,
Python, and C++ can all call JS functions, we just need to ensure it is
*reasonably* fast and easy to deploy.

Lastly, I am sure we will want to introduce "slow validations" - when a
call to an external service, e.g. OSM db or taginfo is required. Those may
be used by some of the tools, e.g. editors right before saving.

Thx!

On Sun, Dec 24, 2017 at 3:03 PM, Colin Smale <colin.sm...@xs4all.nl> wrote:

> Hi Yuri,
>
> We have to decide what is most important - fidelity to the infinite number
> of tagging styles out there, or the ability to get a basic set of tagging
> grammar accepted in as many tools as possible.
>
> Any rules grammar will always have limits of course. If the rules are too
> complex to represent in a declarative way, that is in itself an indication
> of the mess we have got ourselves into. If the "unwritten rules" of OSM
> tagging are too complex to write down, then they need sorting out first!
> Having a simple base to work from might be a good first step. Automated
> chaos is still chaos.
>
> I agree that the ultimate rules engine may well end up using e.g. JS as a
> medium to express some of the subtleties of the rules. Once a JS
> implementation has been published, then people can translate the JS
> reference implementation into whatever language they need. But separating
> the basic rules from the execution engine is nothing more than
> architectural best practice, and there is no reason that the basic
> rules should not be portable across runtime environments.
>
> Can you think of any complex patterns which cannot (easily) be expressed
> in a declarative way?
>
> The real challenge here is not for the coders, but a perennial challenge
> for the OSM community. How do we get to such a consensus about tagging
> patterns, that we can actually say "this is correct" and "this is wrong
> enough to warrant correction" without upsetting a large number of people?
> As soon as a discussion is about right vs wrong, it degenerates into
> mudslinging.
>
>
> //colin
>
> On 2017-12-24 20:37, Yuri Astrakhan wrote:
>
> Declarative rules are usually not very good. Every tool must understand
> every type of rule, and must be updated when new rule types are introduced.
> Plus declarative grammar is either too limiting, or eventually starts
> looking like a scripting language itself, and we end up building an
> execution environment in every tool.
>
>
> I think a better path is executing scripts inside other languages, e.g.
>
> * a JavaScript library ran by Java, Python, C++, ...
> * a lib that gets compiled into a webassembly for browser, or connected to
> other languages via native bindings (less tried path)
>
> The lib would need an API to
> * access local data state
> * access master OSM DB for additional data
> * access other tools like taginfo
>
>
> Integrating scripting environment may be difficult, but offers far greater
> benefits of rule consistency and flexibility.
>
>
> On Sun, Dec 24, 2017 at 7:30 AM, Colin Smale <colin.sm...@xs4all.nl>
> wrote:
>
>> The technical differences between java and JS do not preclude generic
>> thinking. Consider tzdata[1] for example, which does something analogous
>> for time zone data.
>>
>> The "rules database" can be made portable, in the form of XML or JSON for
>> example. The logic for using these rules can be described in a portable
>> way. Then you add a set of compliance tests, and publish a reference
>> implementation to demonstrate that is is possible to implement it. After
>> that, the logic can be implemented in any language you like, checked
>> against the compliance tests and the bindings published.
>>
>> Externalising the rules database enables updates and customisations for
>> particular reasons. Depending on the specific use case and the associated
>> non-functionals, validation could possibly be offered as a cloud service
>> (not necessarily by OSM).
>>
>>
>> //colin
>>
>> [1] https://en.wikipedia.org/wiki/Tz_database
>>
>> On 2017-12-24 12:18, James wrote:
>>
>>

[OSM-talk] Lua modules are here: Improving OSM wiki templates

[Yuri Astrakhan]

Hi everyone.  Thanks to Tom Hughes, we now have Scribunto extension set up
on OSM wiki, which allows Lua language in addition to the very slow and
unreadable wiki template language.

Documentation:
* https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual
* https://en.wikipedia.org/wiki/Wikipedia:Lua

Benefits:
* Much better performance compared with wiki template language
* Substantially more readable
* Allows greater flexibility with how templates are set up

Migration:
The usual migration is to re-implement complex and often-used templates in
Lua (as a Module:* pages), and keep the existing template as a "wrapper" -
a one-liner with {{#invoke:mymodulepage|mymodulefunction}}.  This way
existing pages do not need to be changed, but get all the performance
benefits.

Template info:
Create a "doc" sub-page, e.g.  Module:/doc  and put all the
documentation there.

Testing:
I would advise to create "unit tests" for the complex templates. The
simplest way is to create a   Module:/doc   page with a
table of all possible usages of the module, There is also a good practice
page
https://en.wikipedia.org/wiki/Wikipedia:Lua#Unit_testing

Once again, thanks Tom for helping with this!
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Lua modules are here: Improving OSM wiki templates

[Yuri Astrakhan]

P.S.  If you want to test this new functionality, please use
Module:sandbox/your_wiki_user_namepages (or a subpage of that,
e.g.  Module:sandbox/your_wiki_user_name/my_test_1).
Once the template is ready for usage, you can always rename it to something
else.

On Sun, Jul 29, 2018 at 2:57 PM Yuri Astrakhan 
wrote:

> Hi everyone.  Thanks to Tom Hughes, we now have Scribunto extension set up
> on OSM wiki, which allows Lua language in addition to the very slow and
> unreadable wiki template language.
>
> Documentation:
> * https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual
> * https://en.wikipedia.org/wiki/Wikipedia:Lua
>
> Benefits:
> * Much better performance compared with wiki template language
> * Substantially more readable
> * Allows greater flexibility with how templates are set up
>
> Migration:
> The usual migration is to re-implement complex and often-used templates in
> Lua (as a Module:* pages), and keep the existing template as a "wrapper" -
> a one-liner with {{#invoke:mymodulepage|mymodulefunction}}.  This way
> existing pages do not need to be changed, but get all the performance
> benefits.
>
> Template info:
> Create a "doc" sub-page, e.g.  Module:/doc  and put all the
> documentation there.
>
> Testing:
> I would advise to create "unit tests" for the complex templates. The
> simplest way is to create a   Module:/doc   page with a
> table of all possible usages of the module, There is also a good practice
> page
> https://en.wikipedia.org/wiki/Wikipedia:Lua#Unit_testing
>
> Once again, thanks Tom for helping with this!
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Lua modules are here: Improving OSM wiki templates

[Yuri Astrakhan]

Thanks Jo, now you can copy it to OSM wiki if you think it would be useful!
:)

On Sun, Jul 29, 2018 at 3:06 PM Jo  wrote:

> This is only tangentially related, but I created a Lua module for the
> wikipedias a few years ago:
>
> https://en.wikipedia.org/wiki/Module:OSM
>
> It generates an Overpass Query showing all the objects related to the
> Wikipedia entry via wikidata tags in the OSM data.
>
> Polyglot
>
> Op zo 29 jul. 2018 om 15:01 schreef Yuri Astrakhan <
> yuriastrak...@gmail.com>:
>
>> Hi everyone.  Thanks to Tom Hughes, we now have Scribunto extension set
>> up on OSM wiki, which allows Lua language in addition to the very slow and
>> unreadable wiki template language.
>>
>> Documentation:
>> * https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual
>> * https://en.wikipedia.org/wiki/Wikipedia:Lua
>>
>> Benefits:
>> * Much better performance compared with wiki template language
>> * Substantially more readable
>> * Allows greater flexibility with how templates are set up
>>
>> Migration:
>> The usual migration is to re-implement complex and often-used templates
>> in Lua (as a Module:* pages), and keep the existing template as a "wrapper"
>> - a one-liner with {{#invoke:mymodulepage|mymodulefunction}}.  This way
>> existing pages do not need to be changed, but get all the performance
>> benefits.
>>
>> Template info:
>> Create a "doc" sub-page, e.g.  Module:/doc  and put all the
>> documentation there.
>>
>> Testing:
>> I would advise to create "unit tests" for the complex templates. The
>> simplest way is to create a   Module:/doc   page with a
>> table of all possible usages of the module, There is also a good practice
>> page
>> https://en.wikipedia.org/wiki/Wikipedia:Lua#Unit_testing
>>
>> Once again, thanks Tom for helping with this!
>> ___
>> 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] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Yuri Astrakhan]

I'm a big fan of plus codes, and even have a pending implementation of it
in the Elasticsearch (as an aggregation hashing function).  I doubt there
are any legal restrictions on using this - the code is licensed under
Apache 2, and Google states "Plus codes are free. There are no licensing
fees or other costs. The technology is open-sourced." at https://plus.codes/

Not sure about the implementation complexities.

On Thu, Aug 9, 2018 at 4:35 PM oleksiy.muzal...@bluewin.ch <
oleksiy.muzal...@bluewin.ch> wrote:

> Open Location Codes are also referred to as "plus codes".  Since August
> 2015, Google Maps supports plus codes in their search engine. The algorithm
> is Open Source, licensed under the Apache License 2.0. and available on
> GitHub [1].
>
> A plus code, can be generated at: https://plus.codes/ . It can be entered
> at the Google Maps search input box to find a location. A plus sign "+" is
> inserted in the code for recognition.
>
> It would be nice to have an interoperability. For example, a customer uses
> Google Map, but a dispatcher in a Call Center the OpenStreetMap. The OLC
> has got some interesting features:
>
> "Open Location Codes are derived from latitude and longitude coordinates,
> so they already exist everywhere. They are similar in length to a telephone
> number -- 849VCWC8+R9, for example -- but can often be shortened to only
> four or six digits when combined with a locality (CWC8+R9, Mountain View).
> Locations close to each other have similar codes. They can be encoded or
> decoded offline. The character set avoids similar looking characters, to
> reduce confusion and errors, and avoids vowels to make it unlikely that a
> code spells existing words.The Open Location Code is not case-sensitive,
> and can therefore be easily exchanged over the phone." [1]
>
> [1] https://en.wikipedia.org/wiki/Open_Location_Code
>
> Best regards,
> Oleksiy
>
> ___
> 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] Name:* tags in the local language

[Yuri Astrakhan]

Adding a language=xx to each feature seems excessive, and will be forgotten
most of the time, unless there is some extensive tool support for it.
Adding it to admin regions seems like a better approach.  Some utility
could then calculate a clean translation map, using admin_level number as
the deciding factor in case of multiple values.

On a side note, a validation tool can than be used to check if "name" has
the same value as "name:xx", where xx is taken from that calculated map.
(I'm sure in many cases it won't match because some places use "lang:local
- lang:en" style of naming for the name tag.

On Tue, Apr 24, 2018 at 10:48 PM, Jo  wrote:

> I thought we were already indicating which language name is in, with the
> name:language=:iso tag?
>
> Hmm, apparently not:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/
> Language_information_for_name
>
> Polyglot
>
> 2018-04-24 21:29 GMT+02:00 Richard Fairhurst :
>
>> Paul Norman wrote:
>> > If there's agreement that there is a problem here, I could look
>> > at preparing a mechanical edit or MapRoulette challenge to add
>> > name:* tags, e.g. adding name:en to objects in the US with
>> > other name:* tags, and adding name:zh in China. As an
>> > estimate, this would be 115k changes in China, touching 28%
>> > of roads there.
>>
>> This is pretty fragile too, though. Two minutes after the mechanical
>> edit, a
>> newbie will come along and change the name= tag on a random American road
>> from MLK Boulevard to Martin Luther King Boulevard, without knowing they
>> now
>> have to change the name:en= tag as well. Bang, inconsistent data. Fast
>> forward two years and a bunch of history-losing way splits, and it's no
>> longer clear which is the accurate street name and which is the original,
>> mistaken TIGER-imported one.
>>
>> In theory you could bake support for this into editing software (at the
>> expense of complicating the interface), but even if JOSM, iD, Vespucci and
>> P2 all add support, the name= tag is probably the most likely to be
>> changed
>> by minority editors (e.g. mobile or 'quick fix' apps) and it's unlikely
>> they'll all add the same logic.
>>
>> Mateusz Konieczny wrote:
>> > This language=en tag would be placed on a administrative
>> > relation, right?
>>
>> If I read Frederik's proposal right, the language=en tag would be placed
>> on
>> the object with the name tag, though putting it on admin relations is an
>> interesting idea.
>>
>> Richard
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.
>> html
>>
>> ___
>> 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] 3D models in OSM?! 3D Model Repository has just launched!

[Yuri Astrakhan]

Pedro, thanks for all your efforts!  I heard that Wikipedia just launched
its own 3D file storage, functioning in the similar fashion as their other
files (community curated images/sounds/videos, proper license and
attribution, and file version control).  Do you see your site being in a
direct competition, or somehow helping each other and cooperating for the
common good?  I doubt WMF will implement much functionality for the
OMS-specific goals at this stage.

Thanks!

On Wed, Mar 21, 2018 at 5:45 PM, Pedro Amaro  wrote:

> It is with great pleasure that I announce the launch of the 3D Model
> Repository, available at https://3dmr.eu!
>
> The main aim of the project is to enable a better 3D rendering of OSM
> data, placing 3D models at everything from landmarks, such as the Eiffel
> Tower, to benches on the street.
>
> Starting off from my Google Summer of Code project, over the past few
> months, along with my mentors, Jan (https://www.openstreetmap.org
> /user/osmbuildings) and Tobias (https://www.openstreetmap.org
> /user/Tordanik), I have been working hard on setting up the
> infrastructure required for the launch, namely a web server and the domain,
> which have been warmly provided by FOSSGIS. Along with this, some new
> features and bugfixes were added to the repository, including a PR by
> dkiselev (https://gitlab.com/n42k/3dmr/merge_requests/19). Finally, the
> last few miscellaneous issues before the launch have been resolved, and a
> few sample models were added to the repository.
>
> On the renderer side, -karlos- (https://www.openstreetmap.org
> /user/-karlos-) has been making great progress with OSM go, having
> provided us with an easy way to show off the features of the repository. An
> example rendering can be seen on http://osmgo.org/go.html?lat=4
> 1.69230008=-8.82631887=1.50=351=-7=2=0=beton
> or as an image on https://i.imgur.com/aF5fxFI.png.
>
> ## Contributing
>
> Contributions are always welcome, in any form! There's several ways to
> contribute to the repository, such as modelling or developing. If you know
> how to use Blender or Google SketchUp, you can get started right away
> modelling features of your town, consult the wiki (at
> https://wiki.openstreetmap.org/wiki/3D_Model_Repository) for more
> information. Otherwise, if you'd rather develop, you can implement the
> repository in a 3D renderer (more information available on the wiki at
> https://wiki.openstreetmap.org/wiki/3D_Model_Repository and the API
> documentation at https://3dmr.eu/docs), or add new features to the
> repository itself (a Gitlab repository is available at
> https://gitlab.com/n42k/3dmr). Other than that, if you have any other
> idea, make sure to get in contact.
>
> Hope to see your additions!
>
> ___
> 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] Fwd: DWG policy on Crimea

[Yuri Astrakhan]

On Mon, Oct 22, 2018 at 8:22 AM Mateusz Konieczny 
wrote:

> I think a country relation should describe how the specific country think
> of its borders. So if two countries claim the same territory, those two
> relations will overlap.
>
> That is absurd and conflict with OSM rule to map what exists.
>
On the contrary, it actually matches OSM rules better than deciding
yourself.  When drawing a city outline, you go to that city's government,
and get the geoshape from them. By extension, if you draw a country, you
should use that country's definition.  If two country's definitions happen
to overlap, we ought to document both.

> E.g. it would be illegal in some countries to generate political map not
> according to that country's government.
>
> It is also against Chinese law to publish accurate maps of China. It is
> not a sufficient reason to forbid accurate mapping of China in OSM.
>
I did not say we must abide by laws of every country - would not be
possible in case of conflicts. I only said that some countries require you
to draw maps according to their laws.  China is clearly a special case
here, but other countries are much more reasonable, yet still expect you to
draw their maps for them according to their rules.

> So when I generate a map for Russia, I have to show Crimea as part of
> Russia.  For Ukraine - as part of Ukraine.  Same for China and India and ...
>
> There are also other sources of data. For example to show proper terrain
> shape or to show ratings of restaurants and for many others use cases OSM
> is not sufficient.
>
The argument "it doesn't work for X, therefor we shouldn't make it work for
Y" is puzzling. We can easily make it work for the very practical usecase I
outlined -- drawing countries' borders based on the expectations of a
specific user's location.  Country borders are by definition a
controversial topic without a single answer, and as you said, there are
other data sources for it. Yet we add it to OSM because it has a very
tangible value to the data consumers (who don't have to mix-in multiple
data sources for the basic mapping needs).
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: DWG policy on Crimea

[Yuri Astrakhan]

I think a country relation should describe how the specific country think
of its borders. So if two countries claim the same territory, those two
relations will overlap.

While not ideal, this is preferable for many data consumers - when
generating a map, one always has to consider whom it is being generated
for.  E.g. it would be illegal in some countries to generate political map
not according to that country's government.  So when I generate a map for
Russia, I have to show Crimea as part of Russia.  For Ukraine - as part of
Ukraine.  Same for China and India and ...

On Sun, Oct 21, 2018 at 5:11 PM Mateusz Konieczny 
wrote:

>
>
>
> 21. Oct 2018 15:12 by dieterdre...@gmail.com:
>
> Therefore we can all be satisfied there is clear guidance from the board
> how to deal with this: the local situation determines how we map, and the
> OSMF is explicit here: “National borders are particularly sensitive.
> Currently, we record one set that, in OpenStreetMap contributor opinion, is
> most widely internationally recognised and best meets realities on the
> ground, generally meaning physical control.”
>
>
> https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.
> 
> pdf
>
> When I recently looked at Crimea I noticed it is still part of the Ucraine
> in OSM: https://www.openstreetmap.org/relation/60199
>
>
> Yes, situation on the ground is quite clear here.
>
>
> No matter whatever we like it or not, Crimea is no longer controlled by
> Ukraine and situation
>
> here is quite clear, unlike other affected regions.
>
> We should apply here "Note that OSM follows On the Ground Rule
> .
> Boundaries recorded in
> OpenStreetMap are ones that are the most widely internationally recognised
> and best meets realities
> on the ground, generally meaning physical control."
> ___
> 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] Wikimedia Community Wishlist 2019

[Yuri Astrakhan]

Stefano, thanks!  One important aspect - it seems a single generic request
with guidance gets done much better than multiple smaller items. I highly
recommend uniting behind the general "improve maps" request to get WMF to
commit to maps full time, rather than "throwing us a bone" (creating a
small task-oriented team with a limited time duration).  The current
proposal that is already gaining a lot of discussion momentum is at
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Miscellaneous/Wikimedia_Maps_Improvements

On Tue, Oct 30, 2018 at 11:25 AM Stefano  wrote:

> Dear all,
> WMF has started the call for proposals for next year implementations.
> https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019
>
> Since the OSM community had some 'feature requests' for wiki* projects
> (example: the Map internationalization without using directly OSM), I
> suggest to contribute to these requests now (end of the call November 11th).
>
> https://www.mediawiki.org/wiki/Wikimedia_Maps/Status_of_map_styles
>
> Thanks,
> Stefano
> ___
> 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] OSM Wikibase is now live

[Yuri Astrakhan]

On Thu, Sep 27, 2018 at 9:50 AM Mateusz Konieczny <  matkoni...@tutanota.com
  > wrote:

> Main point of separate presets is that creator of an editor has control
> over it.
>

Mateusz, who should control an app's behavior - the developer or the
community?  Can app make certain editing choices because the dev feels it
should be a certain way, without consulting the community? Can community
make changes impacting the app?  Going too far into both direction seems
bad.  See my other post to Michael -- I think having a structured data
approach allows the dev to easily generate and compare versions of the
rules. This way both the community can easily modify the rules when needed,
and the dev can have a second glance over it, to see exactly what has
changed.

Essentially it is the same problem as with any other wiki, including osm
map data itself -- ease and speed of community's contributions vs
vandalism/errors.  Someone makes a mistake and half of Asia shows as being
under water (I saw that once on WP maps).  Someone else vandalizes NYC
name, and we get a lot of media attention... bad attention.

Devs cannot know all the mapping rules - they cannot be responsible for
checking them all. Instead, it would be better if we build good validation
practices around those rules, so that any vandalism or simple mistakes
become easy to spot, and very quick to fix.

(P.S. Mateusz, sorry for the dup)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM Wikibase is now live

[Yuri Astrakhan]

Michael, thanks for your comments!

The original searchbox functionality has been restored, sorry for the
delay.  See also some related requests to make it even more useful. [1]

I have made some changes to the OpenStreetMap:Wikibase wiki page - could
you take a look?  I would love your help in creating a better guide, so any
feedback, suggestions, and outlines of how it should be done are welcome.
Feel free to even sketch some page content and I will be happy to improve
it with details.

We had 18 wonderful contributors to the new data system in just over a
week, providing hundreds of improvements. This seems to indicate that 1)
there is significant interest, especially in providing translations, and 2)
editing is not extremely difficult.  That said, we certainly should make it
even easier to use.

You do have a point about the validation rules and wiki.  As a developer,
you can create and maintain them yourself. It does require a lot of work,
reduces the number of contributors, and has far less community oversight,
but it gives the developer full control over the rules. Wiki solves most of
it, but gives you less control.  I think one approach is to mix the two,
e.g. run a simple script to generate and store the rules file from the
wiki. Every time you regenerate that file, you will see all the changes,
but you won't have to create them yourself.  Plus all other developers will
be looking at the same data, so there is far better chance of spotting
issues early on.

[1] https://phabricator.wikimedia.org/T190454

(P.S. Michael sorry for the dup, i made a few minor changes)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM Wikibase is now live

[Yuri Astrakhan]

Everyone, please ignore the "don't edit or translate the label"
restriction.  There is now a dedicated ID P16 property.

We can change label to be more useful to the new editors, e.g. "name in
English" instead of "name:en"

Thanks!

On Thu, Sep 20, 2018, 18:01 Shu Higashi  wrote:

> Hi Yuri, thanks for offering this feature.
>
> > When editing, please do not
> > change or translate the "label"
> > field. Only use description field for
> > the translation efforts,
>
> Can you please explain the reason for this? Is it both the label of items
> and properties that should not be translated?
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM Wikibase is now live

[Yuri Astrakhan]

Mateusz, I think we have a chance of success this time because unlike other
rulesets that are stored in the specific project's GIT repos, this project
is
* wiki based and centralized, just like the tag documentation, and
accessible to a much wider community.  In the last week, we had 18 users
making nearly 900 changes (in addition to the original bot import)
* offers tag documentation to the tools, not just rules, so they are more
likely to integrate with it even without the rules, and then switchover
* does not hardcode any structure of the rules - in a way it is "free form"
- allowing incremental growth.

This said, we should take it one step at a time.  First start using it as a
primary key/value multilingual description store and update wiki templates.
Migrate existing tools like TagInfo. Remove duplicate data from template
parameters.

Afterwards, we could expand the scope -- see if we can store validation
rules, presets, etc. for other tools, how complex can we get them, and many
other fun things...

On Wed, Sep 26, 2018 at 11:03 AM Mateusz Konieczny 
wrote:

>
> Part of Wikibase that are an attempt to create yet another preset and
> validator ruleset
> are probably not going to be used by anybody.
>
> Note that so far every editor creates its own (iD, Vespucci, JOSM...).
>
> 23. Sep 2018 14:05 by osm...@michreichert.de:
>
> TBH, if I were an editor developer, I would neither take regular
> expressions for validation rules nor all my presets from the wiki. The
> wiki can be edited by everyone. There are a lot people whose hobby is to
> edit the wiki to make it represent how they expect OSM and the usage of
> tags to be [1].
>
> ___
> 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] OSM Wikibase is now live

[Yuri Astrakhan]

On Sun, Sep 23, 2018 at 2:36 PM Richard  wrote:

> > Key:bridge:movable:https://wiki.openstreetmap.org/wiki/Item:Q104
> > Tag:bridge:movable=bascule:
> https://wiki.openstreetmap.org/wiki/Item:Q888
>
> how do I get at other language's versions, and how do I get easily at the
> original source of the information (description text) to fix it?
>
>
Richard, the original information has not changed in any form just yet.
There are several ways to get to docs from the search box:
* type the exact page name with the language, e.g. "FR:Key:bridge:movable"
and hit enter
* type the exact page name, e.g. "Key:bridge:movable" (without quotes) and
hit enter, Select language at the top.
* type "bridge:movable" and click "search in content" (last item in the
dropdown)
* type bridge:movable, open the wikibase entry, and click the big link in
the upper right corner

I am hoping to enable search autocomplete back, but it might mean that we
won't be able to find wikibase items as easily (which might be ok)

The general hope is that once the data has been copied to wikibase items,
all of the existing {{KeyDescription}}, {{ValueDescription}}, and
{{RelationDescription}} templates will use that data directly. The data
will also be localized - so in a French version of the page, it will
automatically use french descriptions, unless they don't exist, and it
would show English (until translated).

There will be a small link next to each value that came from Wikibase. If
you click it, it will take you to the wikibase entry, where you will be
able to edit descriptions in all of the languages.

 Also, the tables of tags will also be generated directly from that data,
which will allow us not to use all the crazy template inclusion magic (e.g.
using the same table on multiple pages will not require storing it in a
template).
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM Wikibase is now live

[Yuri Astrakhan]

On Sun, Sep 23, 2018, 14:58 Christoph Hormann  wrote:

>
> For clarification:  The main purpose of the OSM wiki is to allow mappers
> to document tags they use and allow them to coordinate and communicate
> about this use of tags with other mappers.


Agree

If you have some data
> collecting application related to OSM tags it would be advisable to
> maintain this outside the OSM wiki - like for example taginfo and
> taghistory do.
>
> Mixing systematic data collection into the OSM wiki is just asking for
> trouble.


Not sure what you are referring to. Wikbase project is designed to be the
primary source of the tag description. This will NOT replace the freeform
wiki page that describe finer points of the tag usage. But it will simplify
the info card, and help all other projects that need tag documentation,
this fulfilling the primary goal even better.

Other projects like taginfo will have an easier time using that data.
Currently, it has considerable and error prone code to parse wiki markup.
Fewer errors and easier data usage should lead to better tools for the
mappers.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM Wikibase is now live

[Yuri Astrakhan]

On Sun, Sep 23, 2018 at 6:34 PM Christoph Hormann  wrote:

> > The content stored in Wikibase is editable by wiki users using a
> > regular wiki account, same as with other wiki pages.
>
> This i have no doubts about - but this is not the question.  The
> question is who is de facto in control of the information and in
> particular who defines what information is considered valid and what
> not.  And by designing the interfaces through which information and
> rules are entered you can pretty well control who will actually control
> the information.
>

Current system - one must know wiki markup to edit description, know how to
structure template parameters, how to create new pages and copy magical
parameters, translatewiki syntax, etc.  New system (once implemented): you
simply click "edit" next to the description of a key, it takes you to the
description page, you click edit again and modify existing description in a
clear form. To add a new language, switch to that language in the upper
right corner if you haven't already, and again - use edit and add the
description.

Unless you suggest that only those who understand wiki markup are allowed
to edit descriptions, the new system is clearly easier.  Also, noone is
stopping us from creating additional dedicated "description editors" -
where you can modify it via some other interface, but still using your wiki
login.

Note that neither old nor new system addresses the "who has the right to
change stuff", and "whose edit is correct".  If you want to propose it -
sure, but even then the new system allows us to build it, whereas the old
one does not.

>
> I am fine with editing the wiki to document tags, i am also fine with
> the various templates in there even if they are sometimes cumbersome to
> understand.  And i acknowledge that technologically the way templates
> are used in the OSM wiki is a dead end.  But this whole wikibase thing
> is repulsive to me in the way it communicates the human editor is
> supposed to serve the computer system and not the other way round.  The
> very idea of making up numerical identifiers for keys and tags which by
> definition already are unique identifiers is ridiculous.
>

You shouldn't worry about numeric identifiers. If you want, I can even show
you how you can hide them from your interface (using CSS). They are not
needed when editing descriptions.  Also, editing template parameters is
also "serving the computer system".

Long story short:  You will never get me to enter or edit tag
> documentation in such an interface which makes me think i have time
> traveled to the last century.


You mean wiki markup-style editing is 21st century? Seriously?


>   You will also not get me to write
> documentation in a place where non-human editors (a.k.a. bots) are
> allowed to modify what i wrote.


Bot is used to initially copy descriptions from the other wiki pages. Once
created, it will not modify description.  Other tools may -- e.g. JOSM or
iD editor could ask the user to enter/modify description in their language,
but it won't be automated. Consider iD editor as an alternative UI to the
wikibase, but the edit will show up as a regular user edit, not a bot.


>   Apart from that if you find a way to
> improve they way in which tag documentation is stored and processed
> without sacrificing ergonomics and intuitive adaptability of the way it
> is entered for typical mappers i will be all for it.
>

Per above, I think it already does - editing template params is by far less
intuitive than filling out a "description" filed in your language.  Also,
it is possible to make a description editor that appear directly in the tag
page (e.g. with a js gadget).
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Help - how to get rid of wrong image in wiki?

[Yuri Astrakhan]

Tag:oneway=reversible was using image Baustellenampel.jpg because English
page had no image, and the Polish translation used it, so it got copied
form PL to the Item:Q5736 and became the default for all languages.  If
that image is incorrect, it should probably be removed from the Polish
translation too so that it would use the one from the data item [1] (I
added the same one as was used by User:Drolbr mdv).  To see the data item
associated with a page, click the "OpenStreetMap Wiki item" in the left
side tools menu, or the gray pencil next to the description.

[1] https://wiki.openstreetmap.org/wiki/Item:Q5736#P4

On Thu, Dec 20, 2018 at 5:59 AM Stephan Knauss 
wrote:

> Roland Olbricht writes:
>
> > https://commons.wikimedia.org/wiki/File:A1_bij_Muiderberg.jpg
> > is the only example I have found at all.
> >
> > Note that this is referenced on
> > https://nl.wikipedia.org/wiki/Wisselstrook
> > and this is still referring to reversible lanes in general, not
> > reversible streets.
>
> Maybe I am confused what you are looking for. Is it examples of roads
> changing the allowed direction multiple times a day, depending on the time?
>
> In Hamburg we have this one:
> https://de.wikipedia.org/wiki/Datei:Sierichstra%C3%9Fe.jpg
>
> If asking nicely the following pictures might be released under an open
> license as well, both pages provide a contact option to ask for usage
> permission:
>
> https://www.hamburg-web.de/fotos/11186-richtungsverkehr-sierichstrasse.htm
>
> https://www.flickr.com/photos/christoph_bellin/15190435328/in/photostream/
>
>
> Stephan
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Sophox is back to life

[Yuri Astrakhan]

Thanks to a kind donation by Elastic (of Elasticsearch fame), we now have a
much cleaner and more stable Sophox service.

Sophox is an RDF database that contains:
* All of OSM data without geometries
* All of OSM Metadata (keys, well known tags, etc) as defined in OSM Wiki
items (with all translations)
* Recent Wikipedia's pageviews statistics
* All polygon geometries that are tagged with the wikidata tag
* A query-driven tag editor

Sophox no longer contains a copy of the Wikidata itself, but it now allows
federation - subqueries that can get data from other SPARQL sources.  Many
example queries in OSM wiki will need to be updated.

Try it (use the blue "play" button on the left side to run the query)
*  http://tinyurl.com/y9tzyonj -- metadata prefix search for keys/tags with
description containing words like "ramp*"

Github: https://github.com/sophox/sophox

If you know SPARQL, please help with examples and documentation.

P.S. Thank you for all your emails asking about it, and offering to help.
Without you, it wouldn't have materialized!
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?

[Yuri Astrakhan]

Frederik,

I suspect the "default" is what the community took the main issue with.
DWG essentially declaring that there must be a single truth for
non-overlapping country borders is what seems to have caused all this.
Simply saying that every country can define their own would have averted
this whole thing.

On Fri, Nov 23, 2018 at 2:24 AM Frederik Ramm  wrote:

> Hi,
>
> On 23.11.2018 01:42, Yuri Astrakhan wrote:
> > One idea (perhaps this should go into a separete thread):
>
> There already is a separate thread over on the tagging list started just
> a couple of weeks ago. I suggest that would be a good place to continue
> the discussion.
>
> Being able to map different claims is certainly interesting, in so far
> as they are verifiable (which surprisingly often is not the case). But
> all that's already been mentioned over at
> https://lists.openstreetmap.org/pipermail/tagging/2018-October/040333.html
>
> I fear that this is only "kicking the can down the road" though because
> we'd likely have - just as we have with names - one "default" set of
> boundaries where we say "that's the one you get if you don't ask for any
> particular one", and the fight would then be on which one that is going
> to be. And judging from how this decision is blown out of proportion
> ("OMG OSM SUPPORTS TERRORISTS!") I am sure that people would display
> exactly the same outrage when discussing which one of a large set of
> mapped claims gets the "default" flag.
>
> >  I especially appreciate 4.2 -- the fact that this decision is very bad
> for the data users --
>
> I think you have misread Victor's 4.2 which essentially says that data
> users currently have to make up their own boundaries anyway and that
> therefore this decision does not *help* them. He does not say that it is
> good or bad, just that it does not improve an already-bad situation.
>
> As for whether
>
> > DWG has gone too far into the political landscape - something I hope it
> did not intend to do.
>
> let me quote from the DWG statement - again:
>
> "The Data Working Group takes no stance on if Russia's control is legal
> or not, as that is not within our scope."
>
> The DWG has simply applied a policy that has existed in OSM since before
> Crimea's annexation. That policy was written by LWG and approved by the
> OSMF board in 2013 and has been applied many, many times since and it
> has generally worked well for OSM. It certainly can be discussed and
> improved but that needs to be on a general level, and not tacking on an
> "Ukraine exemption" to the rule.
>
> 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] OSMF makes a political decision where should be a technical solution?

[Yuri Astrakhan]

Victor, thank you for a very thorough and accurate analysis.  I especially
appreciate 4.2 -- the fact that this decision is very bad for the data
users -- I would not be able to use this data at all, simply because most
of the time one needs to render the map from the perspective of the
specific user, e.g. render it differently for the user in Ukraine, Russia,
or anywhere else for that matter.  I also agree that DWG has gone too far
into the political landscape - something I hope it did not intend to do.

I strongly believe DWG should retract that decision, and the community
should instead devise a proper policy to record all of the relevant data.

One idea (perhaps this should go into a separete thread):
* each country gets its own admin_level=2 relation according to THAT
country. The relation should contain all of the ways outlining the
country's claims (using inner/outer roles). The relation should also
contain sub-relations for each of the disputed territory.
* each disputed territory should be a relation as well, containing the list
of countries that claim its ownership, as well as which countries accept
which position. There could be two (or more) "claimed" tags, e.g. in case
of Crimea -- "claimed:ru=af;ar;be;..." (list of countries that accept RU
claim), and "claimed:ue=*" (everyone else, making it unnecessary to record
every country code)
This way data consumers could decide how to draw each country depending on
the user - simply by combining all of the "claimed:*" tags.

On Thu, Nov 22, 2018 at 1:57 PM Victor Shcherb 
wrote:

> Hi All,
>
> I followed many topics for the last 3 days about the Ukraine/Crimea and I
> would like to propose another look to all known issues.
>
> *DISCLAIMER:*
> First of all, I would like to thank everybody for staying calm and
> considering all views for this *non-trivial* problem. Originally, I'm
> from Belarus (former USSR) and currently I live for a long time in the
> Netherlands, so I hope I can express my point of view objective but also
> explaining the gist of the issue. Even though I'm leading OsmAnd mobile
> development, I will speak solely from my perspective on this question.
>
> *STATEMENT 1. *There is no ToTG principle for artificial objects such as
> boundaries + Boundaries are always driven by one or another authorities.
>
> *1.1 *To clarify that principle we can go the lowest level, city or
> suburb boundaries. it is very clear that it is impossible to identify on
> the ground whether city-suburb has ended and another has started.
> *1.2 *Of course, we can clarify or build it that knowledge from
> milestone, flags or fence. Though we have different Mapping for fence,
> milestone and *we shouldn't mix it with country borders.* Following that
> principle, it will be hard to build polygons cause we always could miss
> data in between or it could be very incomplete from the Ground knowledge
> *1.3 *Most of the data today is coming from authorities. Local
> municipalities provide that public data, so admin_level of lower level
> corresponds to
> *1.4 *There is no ToTG to identify a country, unless you go and do a
> voting on the special piece of terriritory. I think you can find lots of
> places like Kurdistan where people would say that they belong to country
> that doesn't exist or not listed in UN. Country is an entity that coexist
> with other countries and other countries should acknowledge it and
> acknowledge their borders (especially for neighbor countries).
> *1.5 *Fence or any physically present object which could be verified by
> ToTG doesn't make border legitimate and will be very likely removed from
> admin_level relations doesn't matter if it looks or claimed by
> non-authorized entity a special territory if it contradicts to 99.9%
> perception of other mappers.
>
> With this point I'm trying to say, that hiding a solution behind ToTG
> principle we are raising even more questions than we had.
>
> *STATEMENT** 2. *There is no right decision unless we clarify what
> exactly data and how it should be organized.
>
> *2.1 *Moving objects or making special statements about concrete objects
> will drive to a mess. It is obvious that we better focus on Proposal and
> clarify how to deal with data rather than changing the map itself.
> *2.2 *Every mapper should be able to make the right decision himself
> following the wiki documentation. If it is not possible than the
> documentation or rules are not complete or not correct. We should not block
> people that do mistakes in understanding whether their logic correct or not
> especially if it is a significant number of people.
>
> *STATEMENT** 3. *Any decision about current Relations in OSM will be
> political and it will only evolve confrontation between local editing
> groups. I believe OSMF should not take any political decisions in such
> manner.
>
> I truly believe that DWG/ OSMF didn't want to make any political decision
> and only correct the data and make it consistent which makes perfect sense
> 

[OSM-talk] OSM Wikibase is now live

[Yuri Astrakhan]

Osmaritans,

as of today, OSM Wiki can store structured tag metadata similar to
Wikidata.  In every possible language, cross-linked, with images,
validation rules, or anything else the community decides to store there.
See examples:

Key:bridge:movable:https://wiki.openstreetmap.org/wiki/Item:Q104
Tag:bridge:movable=bascule:   https://wiki.openstreetmap.org/wiki/Item:Q888

I have imported most frequent Keys from the TagInfo, plus parsed wiki pages
to try to get multilingual descriptions, images, etc.  Our next step is to
add more descriptive properties, translations, validations(?), better
images. The structured data is accessible via Lua (our new templating
language), so at some point we may want to replace info cards and tables(?)
with the automatically generated ones.

Help is needed: our wiki is large and multilingual. If you can help,
especially if you can run a wiki bot to automate some data parsing and
wikibase item creation, please reply. When editing, please do not change or
translate the "label" field. Only use description field for the translation
efforts, add statements, etc. If you need new properties, please write at
https://wiki.openstreetmap.org/wiki/OpenStreetMap_talk:Wikibase

Other fun links:

Documentation:  https://wiki.openstreetmap.org/wiki/OpenStreetMap:Wikibase
All items:
https://wiki.openstreetmap.org/wiki/Special:AllPages?from===120
Other bridge:movable tags:
https://wiki.openstreetmap.org/w/index.php?title=Special%3AWhatLinksHere=Item%3AQ104=120

Reg-ex based validation rules:
https://wiki.openstreetmap.org/wiki/Item:Q574#P13

For many Key:* pages, you will now see a link on the left side
"OpenStreetMap Wiki item".

P.S.  Big thank you goes to Tom Hughes for helping to launch this project!
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD influencing tagging

[Yuri Astrakhan]

On Sun, Apr 7, 2019 at 1:48 PM john whelan  wrote:

> Tagging is not always easy, highways in Africa are an example.  See a dirt
> track in Europe and its probably a highway=track.  In Africa it probably
> isn't.
>

A "road is a highway" is confusing because the word "highway" has a
different meaning depending on the region. Yet, tagging should not be
ambiguous -- the whole idea about tagging is so that I (the consumer) can
understand what you (the mapper) meant in the most precise way.  A good
example is "denomination=evangelical" -- German speakers should not use it
for "evangelisch" which stands for denomination=protestant. The word may be
the same, but we treat "evangelical" as an ID for a specific meaning,
rather than reflect local language customs.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD influencing tagging

[Yuri Astrakhan]

Martin, thanks for explanation, but my point still stands -- in tags, we
treat words not at their own meaning, but as IDs that represent some agreed
concepts.  The German wiki page has a warning about "evangelical", so it is
likely not all German-speaking mappers are aware of the distinction, or
know English well enough to know this.  The same applies to highways -
"highway" the word has different meaning in different regions, whereas
"highway" the OSM tag should have just a single meaning that's clear to
every mapper and every consumer.

On Mon, Apr 8, 2019 at 3:50 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 7. Apr 2019, at 22:23, Yuri Astrakhan 
> wrote:
> >
> > A good example is "denomination=evangelical" -- German speakers should
> not use it for "evangelisch" which stands for denomination=protestant. The
> word may be the same, but we treat "evangelical" as an ID for a specific
> meaning, rather than reflect local language customs.
>
>
> actually “evangelical” translates in German to “evangelikal”, which
> doesn’t seem to be very confusing. Someone thinking it means “evangelisch”
> is likely mapping in a domain s/he isn’t acquainted with.
>
> Cheers, Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Bot edits on the OSM wiki

[Yuri Astrakhan]

Tobias, thank you for clarification.  The lang parameter was very often
incorrect because people copy/pasted it without changing.  I did a minor
clean up with a manual inspection of every edit - similar to many of my
previous edits (by "yurik" account), but with the bot+minor flag to avoid
exactly the problem that Christoph outlined - to reduce spam in the
watchlist and recentchanges.  Note that the only way you would get a
notification is if you have "Email me also for minor edits of pages and
files" checked on your user preferences page (disabled by default).

The goal of the project [1] is to organize key and tag documentation - make
it available to other systems in a machine readable format, allow JOSM and
iD to get that data directly, and allow users to contribute key/tag/rel
descriptions without the need to create wiki pages (or to even know what
wiki markup is or how to create a template with parameters).  Lastly, this
project will highlight accidental (but numerous) mismatches between
languages -- wiki pages in different languages very often show different
mismatched information in the sidebox (e.g. if it is ok to use on a
node/way/rel, or status). Some cases are warranted, but the vast majority
are simply stale translations.  Eventually the hope is to remove all
parameters from the wiki pages, and just have a  {{TagDescription}} without
any parameters to show an infobox.  It will also allow wiki to avoid tables
of values with duplicated information.

[1]  https://wiki.openstreetmap.org/wiki/Data_items
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Software configuration | Re: iD influencing tagging

[Yuri Astrakhan]

On Wed, Apr 10, 2019 at 5:04 PM Rory McCann  wrote:

> In JOSM, people, or groups, can make their own tagging presets. AFAIK iD
> unfortunately doesn't have this feature. If it did, the iD version on
> openstreetmap.org could be configured to something special, people could
> have their personal tagging presets "saved" somehow, maybe one could
> "load other presets from a remote address" via a URL parameter, allowing
> one to "load a preset with a link".


Rory, I am actually hopping data items could become a general preset
storage for all editors. Each preset would be stored as a data item, and
editors would use a script to convert preset into a JSON file, or
eventually use it directly.  This approach has a number of advantages:

* easy to edit by community, track changes, and fix/revert in case of an
error
* easy to translate - one click description editing for every possible
language
* easy to verify / validate / cross-check - there are many ways to query
presets and to run validations on them, so an invalid preset can be quickly
fixed/reverted
* part of wiki - presets can be viewed as part of the regular wiki pages,
e.g. on a Tag:... page
* easy to add pictures and icons - part of wiki, or from commons - just
another property
* easy to categorize/partition presets - just another property to add
preset into a category, or have a whole category tree.
* easy to extend schema - just add more properties to target a new editor
feature - other editors will simply ignore it.
* ties with all other keys / tags / relations / relation roles -- if a
preset requires a tag, it is not a string, it is actually a reference to
that tag, with its own properties.
* easy to build custom UI -- structured data allows developers to have
custom editors for those presets

Obviously this has to be done in a non-disruptive, gradual way, and having
good quality control. I'm still researching on the best way to achieve this.

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

Re: [OSM-talk] Software configuration | Re: iD influencing tagging

[Yuri Astrakhan]

On Thu, Apr 11, 2019 at 2:10 AM Mateusz Konieczny 
wrote:

> * easy to edit by community
>
> I am dubious whatever "anybody can
> edit any preset stored as wikidata
> items" will be considered as benefit
>

One could also doubt that allowing direct OSM and Wikipedia edits by anyone
would be considered as a benefit... But it does, doesn't it?  Worst
case scenario: someone breaks a preset - with so many eyes on them (exposed
via wiki pages, used by all editors, monitored via numerous tools,
cross-checked by validation queries, etc etc etc), it will be fixed within
minutes.

But we are talking more distant future. The initial idea is to generate
JSON / XML files from data items. So someone edits a data item, a script
will create a Pull Request for preset files. Devs can validate them all
before merging -- you get all the benefits I listed, plus more thorough
validation.

, track changes, and fix/revert in case of an error
>
> All of that is easier with current
> method of keeping them in
> git repositories.
>

Except there are several of these repositories, right? And some are
actually stored as wiki files for JOSM, without an easy diffing? Plus
another place to do translations. Plus there is no way you can see images
as part of those JSONs or XMLs? And plus you have to be a developer to
understand JSON.  But yes, pure iD presets have a good tracking feature in
of itself using github. Just doesn't offer all the other benefits.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Software configuration | Re: iD influencing tagging

[Yuri Astrakhan]

Thx Mark, makes sense. Data items are wiki pages too, and we can protect
them the same way. Still, I think it's a moot point -- at least initially
preset data will go via GitHub as regular pull requests.

On Thu, Apr 11, 2019, 05:34 Mark Wagner  wrote:

> On Thu, 11 Apr 2019 03:17:27 -0400
> Yuri Astrakhan  wrote:
>
> > On Thu, Apr 11, 2019 at 2:10 AM Mateusz Konieczny
> >  wrote:
> >
> > > * easy to edit by community
> > >
> > > I am dubious whatever "anybody can
> > > edit any preset stored as wikidata
> > > items" will be considered as benefit
> > >
> >
> > One could also doubt that allowing direct OSM and Wikipedia edits by
> > anyone would be considered as a benefit... But it does, doesn't it?
> > Worst case scenario: someone breaks a preset - with so many eyes on
> > them (exposed via wiki pages, used by all editors, monitored via
> > numerous tools, cross-checked by validation queries, etc etc etc), it
> > will be fixed within minutes.
>
> Wikipedia is a good comparison, but not in the way you intended it.
>
> Wikipedia has special permissions for changing widely-used
> templates or the website interface itself: the "template editor" and
> "interface administrator" permissions.  An ordinary editor can only
> mess up one article at a time, while a template editor can mess up a
> half-million articles in a single go, and an interface administrator
> can vandalize every page on Wikipedia at once.
>
> If someone breaks the preset for something like "building=yes", then
> sure, it'll be spotted and fixed in a matter of minutes.  But in the
> meantime, there'll be hundreds of mis-tagged buildings, many of them in
> places that nobody will review for years.
>
> --
> Mark
>
> ___
> 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] Bank of India (and other) Wikidata tags

[Yuri Astrakhan]

Andy, you could also use one of the example queries in sophox.org to find
all objects that are usually tagged with brand:wikidata=* (e.g. have more
than 10 instances of that), and find all other objects that use that same
value for wikidata tag.  The query currently finds over 15,000 such
objects, so it runs a ~minute, but limiting it to a 1000 shows up much
faster -- http://tinyurl.com/y5n42qlx

A random look at some of those features shows that many have both wikidata
and brand:wikidata set to the same value (which is surprising).

One relatively painless way of fixing those could be to using Sophox editor
-- essentially a query that will find all cases you want to fix, and allow
you to manually review each one of them (if you are familiar with the issue
and the area), and fix them. See
https://wiki.openstreetmap.org/wiki/Sophox_Editor

On Wed, Apr 17, 2019 at 8:56 AM Andy Mabbett 
wrote:

> There are currently 956 objects in OSM with the tag "wikidata=Q1340361":
>
>https://taginfo.openstreetmap.org/tags/wikidata=Q1340361
>
> where:
>
>https://www.wikidata.org/wiki/Q1340361
>
> is the item for the State Bank of India.
>
> The tag should almost certainly be:
>
>operator:wikidata=Q1340361
>
> or, less likely,
>
>brand:wikidata=Q1340361
>franchise:wikidata=Q1340361
>
> with the only exception perhaps being the bank's HQ.
>
> Can anyone confirm what the correct tag should be, and can we use an
> automated process to correct them?
>
> It's possible that the same issue applies to some of the other
> high--use tags listed at:
>
>https://taginfo.openstreetmap.org/keys/wikidata#values
>
> I've just raised a ticket to ask that Tagnfo display Wikidata labels
> on the latter page, which will make error fixing easier:
>
>https://github.com/taginfo/taginfo/issues/262
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> 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] uselessness of brand:wikipedia and brand:wikidata tags (was Re: Bank of India (and other) Wikidata tags)

[Yuri Astrakhan]

Interestingly enough, FOSS4G San Digeo where I was just attending has had
several talks about wikidata IDs usfulness in OSM...  Also, AFAIK, mapbox
is using WD in brands to do their searches for POIs, as that is much easier
to consume than names. OpenMapTiles have discussed wikidata ids at length,
and consumes it in order to translate many locations (see their
import-wikidata repo).

On Wed, Apr 17, 2019 at 2:42 PM Mateusz Konieczny 
wrote:

>
>
>
> Apr 17, 2019, 11:19 PM by a...@pigsonthewing.org.uk:
>
> On Wed, 17 Apr 2019 at 21:03, Mateusz Konieczny 
> wrote:
>
> Though, if we are lucky this mistake was added by an undiscussed
> automated edit and may be simply reverted.
>
>
> I do not consider the loss of potentially-useful data to be "lucky".
>
> I am not aware about even single case where brand:wikipedia
> or brand:wikidata is useful.
>
> Note that almost always this tags are added based on name tag.
> ___
> 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] Wikibase items instead of usual templates for wiki pages?

[Yuri Astrakhan]

On Tue, Jun 11, 2019 at 12:23 AM Mateusz Konieczny 
wrote:

> Pull requests work and that is exactly scheme used now - by iD, JOSM,
> Vespucci, StreetComplete etc.
>

Ahem, actually no, they do not -- as demonstrated by the recent scandal
with iD presets.  Community is disconnected from developers.


> "Accept all changes from Wiki" or "Treat changes from wiki as submitter
> PR" is unlikely to be considered as preferable.
>
Preferable by whom? The devs? See my previous point -- there is currently a
clear disconnect, and storing presets in the data items is a proposed way
out of that disconnect.

More importantly, I am still not sure I understand what it is that you
object to. A pull request is created by a user who proposes a certain
change to a preset. If the presets are stored in the data items, the
process is nearly the same -- a user proposes a change to a preset, except
that they do it in a wiki, and a bot translates that proposal into the
github's pull request. Same process, but it becomes easier to
analyze/validate/discuss such changes, and to show them in other wiki pages
for everyone to see.

On Tue, Jun 11, 2019 at 12:23 AM Mateusz Konieczny 
wrote:

>
> 10 Jun 2019, 23:07 by yuriastrak...@gmail.com:
>
> On Mon, Jun 10, 2019 at 8:08 PM Mateusz Konieczny
>
> Also, "edit on Wiki automatically and silently starts equivalent of PR" is
> also not going to work.
>
>
> Why a pull request won't work?
>
>
> Pull requests work and that is exactly scheme used now - by iD, JOSM,
> Vespucci, StreetComplete etc.
>
> "Accept all changes from Wiki" or "Treat changes from wiki as submitter
> PR" is unlikely to be
> considered as preferable.
> ___
> 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] Wikibase items instead of usual templates for wiki pages?

[Yuri Astrakhan]

On Mon, Jun 10, 2019 at 8:08 PM Mateusz Konieczny

> Also, "edit on Wiki automatically and silently starts equivalent of PR" is
> also not going to work.
>

Why a pull request won't work?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wikibase items instead of usual templates for wiki pages?

[Yuri Astrakhan]

On Mon, Jun 10, 2019 at 8:03 PM mmd  wrote:

> This idea was recently discussed on Slack US #id channel. To quote Bryan
> on this: "We will never use the wikibase for our presets, sorry".


mmd, this was recently discussed in the iD sync-up call, and Bryan was much
more welcoming to the idea  :)

It doesn't have to be automatic, i.e. adding a new data item preset doesn't
automatically have to show up in iD.  Instead, a bot could create a pull
request for the repo, and let others review it.  Or we could have some
system of accepting presets, and changing their status to "accepted" to be
used.

The key here is that the community will have a much more direct way to
create, edit, review, and accept presets.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wikibase items instead of usual templates for wiki pages?

[Yuri Astrakhan]

>
> I think we need to discuss if this is desired, before any more time is
> spent on adding all of those data items.
>

Joseph, I agree that ideally we should not have duplicates anywhere.
Currently we have thousands of mismatches between languages - e.g. in
statuses and what key/tag should be used on which element.  For example,
see status mismatches --  http://tinyurl.com/y62j5m5e -- (please fix them
in the wiki pages in the corresponding languages, the bot will
automatically update the data items)

Data items are currently auto-generated by a bot from the key/tag pages and
from taginfo statistics.  Data items already allowed tens of thousands of
descriptions to be added for languages that otherwise had nothing - so they
already brought a lot of positive documentation - mostly because they are
far easier to edit than to create a full-blown wiki page and understanding
wiki markup and template parameters.

There has been a number of discussions on the wiki itself (most
wiki-structure specific discussions have traditionally happened there, e.g.
how to organize templates, etc), but I am happy to discuss it in other
venues as well.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wikibase items instead of usual templates for wiki pages?

[Yuri Astrakhan]

Thank you François!  The bot is very cautious - it will not touch anything
that users have edited, e.g. if you edit description in French, it will
never update French, but it will update English if the English page would
change. Same with status property -- if anyone changes it, status property
becomes a taboo for the bot. The bot would never touch other wiki pages
either -- too tricky to track their changes.

--Yuri

On Mon, Jun 10, 2019 at 7:49 PM François Lacombe 
wrote:

> Hi Yuri
>
> First of all, Data Items are great add to OSM wiki and as said this
> already brought real benefits.
> Count on my support to go further with them.
>
> Le lun. 10 juin 2019 à 18:38, Yuri Astrakhan  a
> écrit :
>
>> (please fix them in the wiki pages in the corresponding languages, the
>> bot will automatically update the data items)
>>
>
> What if we update data items directly?
> Will the modification be overwritten by outdated information of wikipages
> or will wikipages be updated according to edit dates?
>
> All the best
>
> François
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wikibase items instead of usual templates for wiki pages?

[Yuri Astrakhan]

Another big advantage is that various tools can use this information
directly from the wiki, without any 3rd party sites - i.e. iD editor gets
new localized descriptions and images the moment they are updated in the
wiki - and we could store other info like validation rules and even solve
the "presets" conflict with this technology -- by storing the presets in
the data items - community would have a direct influence on what presets
should be. (TBD)

On Mon, Jun 10, 2019 at 7:40 PM Andrew Hain 
wrote:

> Some more advantages:
>
> Data item descriptions can be added for tag values that have no need for
> long-form documentation separate from the key.
>
> Descriptions can be added in extra languages before anyone has the time to
> write full documentation in that language; with support from Taginfo this
> means that Map features tables can be generated automatically in all
> languages and not just English.
>
> --
> Andrew
> --
> *From:* Joseph Eisenberg 
> *Sent:* 10 June 2019 13:30
> *To:* Tobias Knerr
> *Cc:* talk@openstreetmap.org
> *Subject:* Re: [OSM-talk] Wikibase items instead of usual templates for
> wiki pages?
>
> > A potential benefit of data items is that language-independent
> information does not need to be manually copied to each translation.
>
> But right now, instead of just checking the English page and the
> translated page (eg Bahasa Indonesia), I have to check the English
> page, the wikibase data item, and the Bahasa Indonesia page to make
> sure they all match.
>
> > The current situation with content duplicated between
> data items and wiki pages isn't really ideal. But there's probably still
> some work left until data items can fully replace the existing systems.
>
> So for there to be any benefit, we would have to get rid of the
> existing templates and switch to only using the wikibase data items,
> correct?
>
> I think we need to discuss if this is desired, before any more time is
> spent on adding all of those data items.
>
> -Joseph
>
> On 6/10/19, Tobias Knerr  wrote:
> > On 09.06.19 13:59, Joseph Eisenberg wrote:
> >> Has this wikibase feature been discussed and approved by the community
> >> in some forum? Perhaps it happened before I was involved with OSM? I
> >> don't quite understand how it works.
> >
> > The way it works is that every tag has a "data item". This is the one
> > for natural=isthmus, for example:
> >
> > https://wiki.openstreetmap.org/wiki/Item:Q19327
> >
> > Of course, you're not expected to find this numeric URL yourself. You
> > can get there from the wiki page for that tag by clicking on a "pencil"
> > icon next to the description in the infobox, or by using an
> > "OpenStreetMap Wiki data item" link that appears in the left-hand menu
> > on every page that has a data item associated with it.
> >
> > The idea behind data items is actually quite similar to how templates on
> > the wiki work: There is a number of possible properties that you can
> > fill in with information. The properties which are currently available
> > are mostly identical to the ones used by the templates: Whether the tag
> > can be used on nodes/ways/..., links to related/required/implied tags,
> > an image, and descriptions in various languages.
> >
> > If some information is omitted from a wiki page, the infobox will pull
> > it in from the tag's data item. Otherwise, the information written
> > directly on the page will take precedence.
> >
> > A potential benefit of data items is that language-independent
> > information does not need to be manually copied to each translation. And
> > while software like Taginfo has been able to extract information from
> > the wiki for a long time, the hope is that this kind of extraction will
> > eventually become easier thanks to data items.
> >
> > I do not believe there has been a community decision to stop adding
> > information directly on wiki pages. So the other wiki contributor's edit
> > was probably premature.
> >
> > Of course, though, the current situation with content duplicated between
> > data items and wiki pages isn't really ideal. But there's probably still
> > some work left until data items can fully replace the existing systems
> > (updating data consumers, plus working on usability and documentation).
> >
> > Tobias
> >
> > ___
> > 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
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Yuri Astrakhan]

On Fri, May 10, 2019 at 3:39 PM Yves  wrote:

> Some validation tools, like Osmose, make great efforts to maintain a
> 'false positive' database.
>

If the same validation is done by multiple tools, they need to share the
"false positive" data, otherwise only one tool would know not to change
something, while another tool will encourage the user to make the same
mistake.

So we either have to set up an OSM shadow database that contains all
exceptions, e.g. "object  is exempt from validation ", or this data
should be stored in the object itself, which seems to be a far more robust
approach (same data store allows data consistency / versioning / user
management / tracking / consistency between tools / same processing
pipeline / ...).

If the objection to this is that users don't want to see junk data, I agree
-- but we could simply dedicate a key namespace to validations, and hide it
by default in JOSM and iD.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk