Re: [OSM-talk] Sophox server down

[Yuri Astrakhan]

The Hetzner hardware gave up, and I have to rebuild it.  Elastic (the
company I work for) has donated their Google Cloud resources, so just need
to spend some time on it, and see if a GCP VM would work as well as a bare
metal box.

On Fri, Dec 4, 2020 at 12:14 PM Yves P.  wrote:

> Hi,
>
> The sophox.org server is down from several weeks. It's impossible to
> query data items 
> Does anybody have news ?
>
> Best regards,
>
> —
> Yves
>
> Keywords: SPARQL, OSM Wikibase, Data Item, Sophox
>
> ___
> 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] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel

[Yuri Astrakhan]

Mikel, I might be misunderstanding what you meant, but in my opinion
conformity is required for this type of project, and I do hope iD/JOSM/...
help us achieve that. To clarify:

* features with the same meaning (type) should be mapped the same way,
otherwise each consumer must understand all of them, and only large
corporations will be able to hire enough people to parse & handle it all.

* it should be relatively simple for the community to add new types, and
later to converge on how to map that new type, thus becoming a new
"standard".

* multiple editors should encourage users to map the same types of features
in the same way.

So yes, conformity is good because it allows us (consumers) to make sense
of the data without having an army of developers.

Hope I'm making sense here, and stating the obvious. Captain out. :)


On Tue, Aug 4, 2020 at 5:08 PM Mikel Maron  wrote:

> Rory, I don't know about you, but I'm certainly hoping for a bunch of
> corporate sell outs rubber stamping iD decisions and squashing the common
> mapper into conformity. Why else would we be doing this?
>
> On Tuesday, August 4, 2020, 04:37:00 PM EDT, Rory McCann <
> r...@technomancy.org> wrote:
>
>
>
>
>
> The Board hasn't decided on how the panel will be
> formed/elected/appointed/choosen. Just because the document doesn't
> address one issue, doesn't mean the opposite, horrible option will
> happen. Do you think I'm going to support some Old Boy's Network of
> corporate employees?
>
> What would you suggest for appointing & transparency?
>
> On 04.08.20 21:30, Christoph Hormann wrote:
> > On Tuesday 04 August 2020, Dorothea Kazazi wrote:
> >>
> >> The OSMF board just published a proposal for a software
> >> dispute resolution panel:
> >> https://blog.openstreetmap.org/2020/08/04/proposal-for-software-dispu
> >> te-resolution-panel/
> >
> > I guess i am asking too much if i envision the board creating a panel it
> > does not control itself...
> >
> > For context - the DWG, which is the traditional and broadly respected
> > entity to resolve conflicts in mapping, is not controlled in
> > composition by the board, it decides on accepting new members
> > themselves.  See also:
> >
> >
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Membership_Policy
> >
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_of_Interest_Policy
> >
> > Significant parts of the authority the DWG has among mappers derive from
> > the fact that it is not composed of political appointees.
> >
> > Interesting also that the composition of the panel is supposed to
> > reflect "all interests of the OSM community" but competence of the
> > panel members on the subject, experience with and knowledge of mapping
> > and tagging in OSM or in other words:  The competence to assess
> > evidence on the cases they deal with and to deliberate on the matters
> > in a qualified and knowledgable way, is not a criterion.  Neither is
> > impartiality on prominent special interests like those of corporate
> > data users.
> >
> > Transparency is limited to the ultimate decisions being made public
> > (indeed important, would be interesting how this would function
> > otherwise).  I guess that means both the nominations and selection of
> > panel members as well as the deliberation and consulting of the panel
> > on cases is going to happen behind closed doors.
> >
>
> ___
> 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 is not the place for dissemination of authoritative data sets

[Yuri Astrakhan]

I second Jóhannes -- every dataset, including OSM itself (hehe) has errors.
Consuming each additional dataset is a complex task -- each dataset has its
own structure and conventions, thus the fewer datasets one has to work
with, the better.  The fundamental problem with 99.9% of the datasets
excluding OSM is a very slow and complex feedback loop - it takes a lot of
efforts to fix an error in the upstream data source.

Should we blindly import everything into OSM? No.
Should we import relevant authoritative sources, tagging them as such, and
using them especially for cases like disputed borders? Certainly,
especially because in OSM we can fix the issues we notice with them.

On Thu, Mar 19, 2020 at 12:56 PM Jóhannes Birgir Jensson 
wrote:

> As someone who started as a foot mapper but who is now also in an
> "authoritative position" I'd like to answer Frederik here.
>
> Amongst my professional responsibilities is the dissemination of the
> authoritative data set for protected areas in Iceland. Many of these are
> huge, do not have lines drawn on the ground (or water or sea) and can only
> partially be mapped on foot.
>
> However I believe including them is beneficial for OSM and its users and
> so have been doing updates as I can. However it is not an easy process for
> large areas, having to chop the huge Vatnajökulsþjóðgarður (over 15% of
> Iceland) up due to max nodes is not an easy feat - and now I have to update
> it due to expanded boundaries and quite honestly it is a daunting task (it
> will be easier to delete it and re-import it in a very time consuming
> manner).
>
> So - why are authoritative data sets an unwelcome addition? I have many
> data sets that I need to disseminate but only some are useful for OSM (in
> my view). Also keeping them in sync can get harder as the key-cleanup crew
> was roaming around recently.
>
> Do we just want things we can see, not things that are real, have a basis
> in law, and you can get arrested for doing the wrong things in the wrong
> areas?
>
> Things are not black and white, data sets are of different qualities and
> such a sweeping statement is not helpful.
>
> --
> Jóhannes / Stalfur
>
> 19. mars 2020 kl. 11:35, skrifaði "Frederik Ramm" :
>
> > difficult to import "authoritative data sets"; the problem is that
> > authoritative data sets are fundamentally incompatible with the way we
> > operate in OpenStreetMap. To quote just an obvious example, the
> > government of India certainly has an authoritative data set about where
> > their boundaries are, it's just that this does not align with facts on
> > the ground and hence our data is different. The past has shown that
> > petrol station chains also have "authoritative" data sets about their
> > stations but they are riddled with bugs, and not suitable for wholesale
> > import.
>
> ___
> 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] Creation of "Data Items" by bot for undocumented tags

[Yuri Astrakhan]

It is very strange that we, on one hand, allow anyone to create any kind of
tags (just type it in), and on the other we create so many hurdles to
document it (we refuse to allow a wiki page about an item, but instead
demand that each key page go through a proposals process, approve it,
etc).  I believe this is a ridiculous situation solvable with the data
items.  If I, the editor, create a new tag, I should have a way to type in
a short textual description (one/two sentences) explaining what that tag
is.  Without knowing how to create wiki pages or data item pages or using
the right templates, or even knowing which fields to fill out where. Data
items allow for that.

When a data item is created automatically, it makes the process of adding
such documentation very straightforward -- e.g. if one uses iD editor, they
simply expand the (i) button next to the tag, click edit, and type in the
description.

Moreover, it should be possible to do so directly from iD, without going to
another page. The eventual goal is to make it simple to add such
descriptions __without__ leaving the current editing tool (iD/JOSM/...) and
without visiting the wiki.  These tools will be able to view other metadata
as well -- e.g. if this tag should be usable on a way/node in a consistent
way, regardless of the language of the user.

On Tue, Feb 18, 2020 at 5:54 PM Andrew Hain 
wrote:

> I strongly disagree.
>
> It is perfectly useful to document the existence of tags in the database
> with data items. For example one was created for the key sub_sea:type [
> https://wiki.openstreetmap.org/wiki/Item:Q4506] and it has been possible
> to add this it is a discardable tag that the main OSM editors remove when
> editing. While it is possible in principle to add a long form tag
> documentation page, and indeed the presence of the data item is a record
> that one may be worth writing, it needs a different set of skills to
> research its content. As such the data item and others like it are useful
> on their own.
>
> --
> Andrew
> --
> *From:* Joseph Eisenberg 
> *Sent:* 18 February 2020 17:28
> *To:* osm 
> *Subject:* [OSM-talk] Creation of "Data Items" by bot for undocumented
> tags
>
> Data Items should not be created by bot for undocumented tags.
>
> According to
> https://wiki.openstreetmap.org/wiki/Data_items#Item_Creation_Process
> the Data Items (aka "Wikibase" or "Wiki Data items") are automatically
> created by a bot, even before a tag is documented, if a tag has a
> certain standard format and more than 10 uses in the database.
>
> The data item is created in this case with the text "‎Created a new
> Item: Auto-updating from Wiki pages" - e.g.
> https://wiki.openstreetmap.org/w/index.php?title=Item:Q19947=history
>
> This is confusing to users. For example, Item:Q19947 above,
> "landuse=research" was created before there was a wiki page. Then
> yesterday a user documented the tag with a page, but did not
> understand why there was already a data item:
>
> "Wikibase entry: evidence for preceding deletion? I've just created
> landuse=research, but the data item
> https://wiki.openstreetmap.org/w/index.php?title=Item:Q19947=history
> was already existing in December '19. How was the data item then
> created?"
>
> https://wiki.openstreetmap.org/wiki/Talk:Wiki=#Wikibase_entry:_evidence_for_preceding_deletion.3F
>
> Besided the potential confusion caused by creating these items by
> bots, I think it is a bad idea to encourage wiki users to start
> editing these data items without first creating an actual
> human-readable wiki page to document the tag.
>
> In theory, the "Data Items" can be useful if they properly document
> how tags are used, in a way that is easier for computers to handle,
> but this only works if the data is maintained and updated.
>
> Creating a new wiki page (by human) will alert other users via
> "Special:Recent" and "Special:NewPages", while the stream of items
> created by bots is too much for humans to maintain, and the page names
> are too obscure (Item: Q19947 is meaningless) to be scanned by humans.
>
> Therefore, I propose that Yurikbot be changed to only add new data
> items for documented tags which already have a wiki page in at least
> one language. I do not see a benefit to creating date items for
> undocumented tags.
>
> Joseph Eisenberg
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Testing torrents for the planet dump

[Yuri Astrakhan]

Christian, I would like to add torrent support to the download-osm tool
[1].  While I could try to scrape
https://osm.cquest.org/torrents/ , I would obviously rather use the
structured xml file (or if you could provide a JSON file, even better).

Proposed logic:
* get the catalog file (xml/json)
* download the latest torrent
* (TBD) possibly use some magical aria2c options to stop the download if it
is not progressing and fallback to regular http, or possibly pick a
slightly older torrent (?).  Suggestions are welcome -- see full list of
aria2c options [2]

[1]
https://github.com/openmaptiles/openmaptiles-tools#multi-streamed-osm-data-downloader
[2] https://aria2.github.io/manual/en/html/aria2c.html

On Sun, Feb 9, 2020 at 12:44 PM Christian Quest 
wrote:

>
> Le 09/02/2020 à 18:26, Maarten Deen a écrit :
> > On 2020-02-09 16:17, Christian Quest wrote:
> >> A couple of weeks ago, I've (re) started sharing planet dump files
> >> using Bittorrent to test an alternative way to distribute our planet
> >> dumps to reduce the bandwidth load on the OSMF servers.
> >>
> >> Here is a short summary after 2 weeks tests...
> >>
> >> The torrents are generated a few hours after the planet dump
> >> availability on planet.openstreetmap.org server (time needed to
> >> download the original file to generate the torrent).
> >
> > A question about updates of the torrent. The planet changes weekly.
> > Suppose I download the plannet using the torrent and then also seed
> > it, what happens when the next planet comes available? Do I need to
> > use a different torrent to download it again or will the one I have be
> > updated?
> Each planet file has its own torrent. A new planet file means using a
> new torrent to download it.
>
> To simplify downloading the lastest planet, you'll find a
> planet-latest.pbf.torrent similar to the planet-latest.pbf (it's a
> symlink to the last planet available).
>
> If you want to automate downloading new planet thru torrents, for
> example to seed them, there's a rss.xml file you can use. Many
> bittorrent clients support RSS to automate downloads.
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Yuri Astrakhan]

I am in favor of this or similar language.  I think for a more vote-like
discussion it might be better to use the wiki talk page (easier to add +1s
and short comments).

On Sat, Feb 8, 2020 at 2:59 PM stevea  wrote:

> I don't know if here or https://wiki.osm.org/wiki/Talk:Good_practice is a
> better place to discuss and eventually insert these suggested improvements
> into https://wiki.osm.org/wiki/Good_practice#Verifiability (and its first
> section, "Map what's on the ground").
>
> I suggest adding these essences of this thread there:
>
> "'Independent verifiability' is a crucial component of the Good Practice
> of mapping what is on the ground, as sometimes there IS no evidence
> on-the-ground that a map feature should be appropriately tagged anything in
> particular.  For example, some boundaries are effectively invisible, but
> OSM maps them (and should).  Also, there are no or few signs which say
> "Pacific Ocean" or "Rocky Mountains," yet OSM authoritatively maps these
> natural=* features with an agreed-correct name=* tag.  Similarly, there are
> routes (road, bicycle, hiking, equestrian...) which might exist on a
> government-published map (and hence are ODbL-compatible) yet remain
> unsigned (or poorly signed) in the real world.  From what authority must we
> determine the source "verifiability" of these "invisible" or "unsigned" map
> features?  As long as these are "independently verifiable" (by a government
> map, legal / statutory decree, data authoritatively published on a website,
> by unanimous agreement among locals and a wider public or at least with
> very wide consensus), the map feature with its verifiable tags may be
> entered into OSM following Good Practice.  'Independent verifiability'
> means any member of the public, freely, anytime and with no special
> privileges can 'consult the source' and verify the data."
>
> I'm simply tossing that out here, if it shouldn't stick, please fix it.  I
> think it important that the phrasing is first vetted (here or on the Talk
> page) and I do think something like this should be entered into our
> Good_practice wiki to clarify OTG as we have discussed it here.
>
> Thanks in advance for any brief review and comments / suggestions you
> might offer,
> SteveA
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM/LondonOSM | Re: Crimea situation - on the ground

[Yuri Astrakhan]

Thanks Rory, that's an interesting case.  One thing of note is grouping
names by language/dialect is fairly common but still arbitrary division --
i.e. it assumes that a group of people speaking one language/dialect have
no contradictions in naming something.  But just like we should not assume
language is the same as a location for wiki documentation, names could also
differ depending on location rather than name.

A case to the point:  Russian speakers from New York tend to say "in
Manhattan" (meaning -- in the city/borough of Manhattan), where as Russian
speakers from everywhere else tend to say "on Manhattan" (on an island of
Manhattan). I suspect this has cultural roots -- there was a popular song
with words "live on Manhattan" that recently made that expression popular
everywhere except for the Russian-speaking NYC populace.  Of course this is
not something we need to document in OSM, but it highlights that language
is not homogeneous with naming and just makes a fun story :)

On Sat, Feb 8, 2020 at 6:22 AM Rory McCann  wrote:

> On 07.02.20 20:22, Yuri Astrakhan wrote:
> > (e.g. two fairly large groups of people could refer to the same
> > place/object by different names). ... the map should be able to
> > reflect difference of opinions to some "reasonable" degree (an
> > intentionally vague term).
> One useful example of that is a city in the north west of the island of
> Ireland, called (in English) either Derry or Londonderry. Everyone
> agrees on the Irish name (`name:ga`) (
gaDoire
). OSM's
> multilingual tagging scheme, but for dialects, are used to differentiate
> the Hiberno-English (en_IE) name (
en-IEDerry
) from the
> British-English (en_GB) term (
en-GBLondonderry
). The `name`
> tag uses the commonly used compromise. That approach could work for
> other areas.
>
> RFC 1766 (for IETF language tags) appears to allow quite detailed
> specification of languages & areas, and could be useful.
>
> https://www.openstreetmap.org/node/267762522
> https://tools.ietf.org/html/rfc1766
> https://en.wikipedia.org/wiki/IETF_language_tag
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Crimea situation - on the ground

[Yuri Astrakhan]

Thanks Stevea, I really liked your examples. And thank you Mikel - I agree.
OSM already has substantial amount of non-physical but relevant information
(e.g. many IDs pointing to external registries), and as Stevea points out -
even naming for something local could be contradictory (e.g. two fairly
large groups of people could refer to the same place/object by different
names).  I also think OTG should be a general guideline/goal, simply
because map could not be complete without some of that information, and the
map should be able to reflect difference of opinions to some "reasonable"
degree (an intentionally vague term).

On Fri, Feb 7, 2020 at 2:15 PM stevea  wrote:

> Without touching the Crimea specifically, I'd like to chime in that
> "on-the-ground" (OTG) is a good rule, but in reality it must be approached
> more like a goal to be achieved where it can be, as we must acknowledge
> that realistically, this rule both cannot be and is not applied everywhere
> under all circumstances.  That is the simple truth and OSM should not
> pretend otherwise.  Maybe we need to tighten up our language about how we
> define OTG to better acknowledge this, clearly and explicitly.
>
> A well-known example is (national, other) boundaries, which frequently do
> not exist "on the ground," but our map data would be remiss if it excluded
> these.  So we do our best to include boundaries even as they are not
> on-the-ground, but exist in both de pure and de facto ways in the real
> world, so OSM expresses them.  Yes, when boundaries are disputed, this is
> difficult:  there is no way around that and it isn't unique to OSM.  I like
> Mikel's recent suggestion positing that OSM can better develop tagging that
> accommodates a wide array of disputes, as we do have plastic tagging and it
> can evolve well.
>
> Other examples include large bodies of water and mountain ranges.  I've
> lived on the Pacific coast most of my life and been to dozens of beaches,
> but never once on any beach have I seen a sign which reads "Pacific
> Ocean."  Same with no signs at the edge of or in the middle of "Rocky
> Mountains" or "The Alps."  (I've been, and I haven't seen).  Yet, OSM maps
> oceans and mountain ranges.  How do we know their names without anything on
> the ground?  It's a tricky question which usually starts with some
> hand-waving (especially for enormous, major-chunk-of-planet-sized entities
> like oceans), and progresses to "well, everybody simply KNOWS that's the
> Pacific Ocean..." and we are faced with OTG and an inherent contradiction
> of what we should do, then we do it anyway.  (Name something without having
> a solid OTG reality).
>
> To a lesser (weaker) extent, OTG flexibility might also apply to newly
> developed routes (bicycle routes are a good example) as these may not be
> signed (or well signed), yet a government (whether local, state or
> national) expresses these as real (on a public map — just as with a
> boundary) and poorly signs or doesn't sign them at all in the real world.
> OSM uses "unsigned_ref" to denote these, but it's a fuzzy semantic that
> doesn't have wide agreement or even consensus.  I have seen the opinion
> that these shouldn't be in OSM at all, which seems a shame for things which
> many local users (of a bike route decreed by a government, for example)
> agree do "exist," yet there isn't any OTG evidence for this.  While one
> tenet of OSM is "don't copy from other maps," when the only evidence that
> something exists is ONLY from a PUBLIC map (yielding us ODbL permission),
> we have to reconcile that with OTG.  Today, we don't do that very well.
>
> So, rather than being fully enthusiastic about the absolute application of
> OTG (we simply can't), let's realize that it is a good guideline which
> should be followed where it can, yet it must include some flexibility which
> allows for exceptions.  I haven't seen that said (here, yet, perhaps it is
> elsewhere) and I believe it is important to be explicit about it.
>
> SteveA
> California
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] weeklyOSM #497 2020-01-21-2020-01-27

[Yuri Astrakhan]

Andy, I agree that being frugal with bandwidth is important.  Yet, there is
a significant operations cost involved here, that I suspect very few will
actually be willing to spend, unless it is made trivial -- the cost of
setting up an independent planet file update pipeline - i.e. a docker image
that could be pointed to a planet file, and has an easy way to suspend and
resume update when the file needs to be static during the loading process.

I think having an optimized download tool that can both download+validate
planet/areas, and could provide other services like diff updating would
solve both goals.  If the current process is manually pick a mirror,
manually validate, and re-download if failed, vs use a dedicated tool that
will optimize the download and crash recovery, all the better. Especially
if it offers us a way to add more functionality later, like patch updating.

Also, lets not fall into the premature optimization trap, as that only
achieves local rather than global maximums.  As a theoretical example -
what is better - wider OSM adaption with higher number of planet downloads
(i.e. some wasted bandwidth), or lower adaption and more optimized download
process?  I would think OSM project would be better off from wider adaption
at a cost of a 10-50% extra bandwidth, right?  If the startup cost (human
hours) is lower, more people would participate.  My numbers could be
totally off, but keeping the eyes on bigger picture is very important when
deciding such matters.  Convenience/low manual labor cost is a big
contributor to wider adaption.

P.S. Am I correct to assume that every data consumer would need to download
each diff file twice -- once for planet file update, and once to update the
PostgreSQL database?


On Sun, Feb 2, 2020 at 4:17 PM Andy Townsend  wrote:

> ... that's why I said "... and there are ways of keeping a *.pbf* up to
> date" in my message. - the idea is to avoid large downloads wherever
> possible (emphasis new in this message; won't make it to plain text
> archive).
>
Andy,


> For more info see:
>
> https://docs.osmcode.org/pyosmium/latest/tools_uptodate.html
>
> or if that's somehow not an option:
>
>
> https://wiki.openstreetmap.org/wiki/User:EdLoach#Osmosis_to_keep_a_local_copy_of_a_.osm_file_updated
>
> (from a few years back)
>
> * Automation / easy adaptation.  Providing an out-of-the box way to set up
> your own server is much easier if you have a tool that automatically
> downloads and validates the planet file or a portion of it,
>
> Sure - an automated process is much easier to follow than a manual
> do-it-yourself one, but the fact that a process is automated doesn't mean
> that it has to be wasteful.  Ultimately, someone's paying for the bandwidth
> that downloads from each of the mirrors at
> https://wiki.openstreetmap.org/wiki/Planet.osm#Planet.osm_mirrors use, so
> it seems only fair to not be profligate with it.
>
> Best Regards,
>
> Andy
>
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] weeklyOSM #497 2020-01-21-2020-01-27

[Yuri Astrakhan]

Andy, two major reasons:

* Anyone working on an evolving project like OpenMapTiles would attest that
the import schema constantly changes. Every time schema changes, one needs
to download newest planet, import it based on the new schema, and run diffs
from that point.

* Automation / easy adaptation.  Providing an out-of-the box way to set up
your own server is much easier if you have a tool that automatically
downloads and validates the planet file or a portion of it, rather than
forcing each user to find the proper mirror, wait for an hour to download
it, only to find out that somehow that mirror has invalid data (my tool
finds when one mirror has slightly off file lengths and ignores it -
already happened several times, and it also auto-validates the file with
md5)

So yes, not having a tool is worse than having it for the above reasons.
Also, considering that others have already twitted about it, and a lot of
other OSM/geo community has liked it, it seems the tool has value to at
least some people, thus warrants inclusion in a newsletter.

On Sun, Feb 2, 2020 at 11:02 AM Andy Townsend  wrote:

> > For those who download OSM data regularly, there is now a simple way to
> reduce the load on the primary OSM servers, while also making download much
> faster and ensure the data is correct.
>
> Apologies if this has been done to death already, but surely if you are
> downloading the entire planet regularly you are quite simply "doing it
> wrong"?
>
> Minutely (and other frequency) diffs exist, and there are ways of keeping
> a .pbf up to date (both osmium-based and osmosis-based, if for some reason
> the former doesn't work for you).
>
> A "tool" that downloads from all mirrors in parallel just leads to a
> "tragedy of the commons" situation, and isn't a solution to the underlying
> problem of scarce resources.
>
> Best Regards,
> Andy
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] weeklyOSM #497 2020-01-21-2020-01-27

[Yuri Astrakhan]

The news mentions that downloads from Planet OSM are currently rate limited
to 400 kB/s and suggest to use mirrors, but does not mention the related
announcement about the new tool to simplify such downloads. I think it will
help anyone downloading, and it might be worth including in the next
weekly. Original announcement:



For those who download OSM data regularly, there is now a simple way to
reduce the load on the primary OSM servers, while also making download much
faster and ensure the data is correct.

OpenMapTiles new tool downloads the planet from all mirrors in parallel. It
usually takes just a few minutes, and it automatically verifies md5
checksum.  The tool will not use the primary planet source by default.  The
tool can also download and validate regional extracts from geofabrik,
bbbike, and osmfr.  Internally the tool uses aria2c.

Easiest is to use it with the docker -- share current dir with docker and
save the file there. Anything after the "--" is passed to aria2c. Here's a
Linux/Mac command, but should be runnable from Windows with the minor
command adjustment.

  docker run --rm -it -v $PWD:/download openmaptiles/openmaptiles-tools
download-osm planet -- -d /download

Use  --dry-run (-n)  to run it without the actual download (i.e. to see
which file it would download and from what mirrors). You may also add
--verbose (-v)

  docker run --rm -it openmaptiles/openmaptiles-tools download-osm planet
--dry-run

Use --help for all arguments.  See source and documentation here:
https://github.com/openmaptiles/openmaptiles-tools#multi-streamed-osm-data-downloader

P.S. Conceptually, the script is doing for OSM data what torrents were
designed to do, but sadly there is no well established web of torrents that
would offer similar functionality.

On Sun, Feb 2, 2020 at 9:29 AM weeklyteam  wrote:

> The weekly round-up of OSM news, issue # 497,
> is now available online in English, giving as always a summary of a lot of
> things happening in the openstreetmap world:
>
>  http://www.weeklyosm.eu/en/archives/12814/
>
> Enjoy!
>
> Did you know that you can also submit messages for the weeklyOSM? Just log
> in to https://osmbc.openstreetmap.de/login with your OSM account. Read
> more about how to write a post here:
> http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm
>
> weeklyOSM?
> who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
> where?:
> https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
> ___
> 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] New tool to download OSM data from all mirrors in parallel

[Yuri Astrakhan]

For those who download OSM data regularly, there is now a simple way to
reduce the load on the primary OSM servers, while also making download much
faster and ensure the data is correct.

OpenMapTiles new tool downloads the planet from all mirrors in parallel. It
usually takes just a few minutes, and it automatically verifies md5
checksum.  The tool will not use the primary planet source by default.  The
tool can also download and validate regional extracts from geofabrik,
bbbike, and osmfr.  Internally the tool uses aria2c.

Easiest is to use it with the docker -- share current dir with docker and
save the file there. Anything after the "--" is passed to aria2c. Here's a
Linux/Mac command, but should be runnable from Windows with the minor
command adjustment.

  docker run --rm -it -v $PWD:/download openmaptiles/openmaptiles-tools
download-osm planet -- -d /download

Use  --dry-run (-n)  to run it without the actual download (i.e. to see
which file it would download and from what mirrors). You may also add
--verbose (-v)

  docker run --rm -it openmaptiles/openmaptiles-tools download-osm planet
--dry-run

Use --help for all arguments.  See source and documentation here:
https://github.com/openmaptiles/openmaptiles-tools#multi-streamed-osm-data-downloader

P.S. Conceptually, the script is doing for OSM data what torrents were
designed to do, but sadly there is no well established web of torrents that
would offer similar functionality.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD as default editor

[Yuri Astrakhan]

check your OSM settings. AFAIK, iD is the default editor.

On Mon, Dec 23, 2019 at 2:10 AM Sören Reinecke via talk <
talk@openstreetmap.org> wrote:

> Hello,
>
> so far I know currently Postlatch is the default editor on osm.org .
> Since it needs Flash to run and most users do not have Flash anymore,
> clicking on the "Edit" button leads to almost blank page. Without knowing
> that you need to change Postlatch to iD in settings, you're lost as newbie.
> This is not very beginner friendly
>
> Are they any plans to make iD the default editor or is iD already the
> default editor?
>
> Cheers
>
> Sören Reinecke alias Valor Naram
>
>
>
> ___
> 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] Wiki templates and DataItems

[Yuri Astrakhan]

I would love to fully transition to data items, as it would make
translation and cross-language tag consistency far easier.

We now have a data item editor you can enable by going to preferences /
gadgets, and enabling it.
*
https://wiki.openstreetmap.org/wiki/Special:Preferences#mw-prefsection-gadgets

Once enabled, it creates WEF links on the left sidebar. Go to a regular
wiki key or a tag page, and click the key/tag link in the sidebar.

On Fri, Nov 22, 2019 at 11:24 AM François Lacombe 
wrote:

> Hi all,
>
> It's been a while we use to complete templates KeyDescription and
> ValueDescription on wikipages which are then crawled by a bot completing
> DataItems
> https://wiki.openstreetmap.org/wiki/Data_items
>
> According to topics like : https://github.com/taginfo/taginfo/issues/263
> and last SOTM discussions, there is still a lack of consensus about
> DataItems usage.
>
> Where are we going now?
> Is there something else than consensus, TagInfo and mainstream editors
> connectors missing preventing us to move?
>
> I find DataItems really relevant to tackle the translation challenge, just
> like WIkipedia did with WikiData.
> Editors and QA could take a great advantage to get data from standard
> properties instead of parsing wikicode, couldn't you?
>
> 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

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[Yuri Astrakhan]

Stevea, I think this discussion mixes two topics, as Martin pointed out:
* I want to be credited for my work (i.e. you couldn't have done it without
me, just say so)
* I want to control what you do with the results of my work (i.e. you must
not kill baby seals using the map I created)

The first one is mostly a social construct, and most of the time we are ok
if someone just says "came from OSM" - because then we know others will
want to find out more, and join the project, growing the community, and
essentially giving back to what you believe in. E.g. if i donate $5 to the
grow a tree (Arbor Day) foundation, my money is mostly useless unless you
also donate to them.

The second is different. It's a legal weapon, something we can use when our
sole existence is at stake. We will have to spend money and time defending
it. When OSM started, some people didn't want Google to benefit from the
volunteer efforts without giving back (see point #1). So they went into all
sorts of legal mambo jumbo to prevent such unholy use.  They were
successful - Google hasn't used the data directly.  It would be very hard
to say if this did more damage than good to the OSM project itself (rather
than if we used CC0 license), but it has been done.

Yet, forcing public domain data to be distributed under a more restrictive
license just because we want to be nitpicky about the letter of the license
achieves neither of the above goals.  Rather, it scares users away.  I
seriously doubt of the validity of this legal theory, but even if it is
correct, it is not in OSMs best interest to pursue such restriction. It
does not gain us anything, and causes a lot of collateral PR damage in the
process.

On Thu, Nov 14, 2019 at 6:29 PM stevea  wrote:

> I don't know.  I've expressed my opinion(s) on the matter, and believe the
> LWG should chime in with "an" (the?) answer.
>
> SteveA
> California
>
> > On Nov 14, 2019, at 3:27 PM, Martin Koppenhoefer 
> wrote:
> > sent from a phone
> >
> >> On 15. Nov 2019, at 00:19, stevea  wrote:
> >>
> >> But the "ultimate test" of "can the new work be made without OSM data?"
> remains a good one, in my opinion, because then, the author can be told,
> "well, then, go do so, please, otherwise offer us attribution of some sort"
> (whether legally required, or not).
> >
> >
> > if you distribute a dataset and say: all roads but not those in
> OpenStreetMap, isn’t this already attribution? The question is whether
> you’d want to force them to distribute under ODbL rather than MIT (and
> maybe what the downstream users have to attribute).
> >
> > Cheers Martin
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[Yuri Astrakhan]

stevea, I would not be exactly the same person without OSM. Does it mean
ODbL applies to me?  A hammer was used to build a house, but the house does
not have hammer's copyright. Just because some data was used in the process
does not necessarily mean that whoever saw that data taints everything they
touch from thereon with ODbL license. In some cases it does, like when
portions of OSM data make it into the final product, but I seriously doubt
that if someone computes average time OSM editors contribute to the OSM
project, and publishes that average, and afterwards someone else publishes
how often someone publishes papers about OSM community, they must use ODbL
license... Even though that last research paper would not be possible
without the first research paper, which would not be possible without OSM
data.

On Thu, Nov 14, 2019 at 5:53 PM stevea  wrote:

> While exactly "the data" may not be "in" the derived work, because of the
> process of their creation, "their spirit" are in the derived work, as they
> were a part of the new data's production.  That strongly seems "derived" to
> me, whether that "spirit" is inspirational or gives rise to "do include
> this, don't include that."  These decisions are based upon OSM data, so OSM
> is being "derived" to make the new work.
>
> Again, if the data aren't derived from OSM, please create them exactly the
> same withOUT OSM data and "then we shall see" (whether OSM data are
> necessary or optional for the new work's duplicate creation).  If you can
> do that without OSM data, please do so.  If you MUST use OSM data (even if
> no actual OSM data end up in the final work), then please agree that the
> final work is at least partly derived from OSM data.
>
> This doesn't seem that difficult to do on a verbal level, though again,
> I'm not sure of how it holds up legally.
>
> SteveA
> California
>
> > On Nov 14, 2019, at 2:45 PM, Martin Koppenhoefer 
> wrote:
> > I guess the law often doesn’t work like common sense. ODbL says it
> protects the database or a substantial extract of it. Where’s the data from
> OSM in this dataset?
> >
> > Cheers Martin
>
> >> On 14. Nov 2019, at 23:25, stevea  wrote:
> >>
> >> But if you DO use that "OSM over-layer," then please:  agree with
> common sense that those work are derived from OSM, even if they do not
> contain OSM data in them.  They contain data "helped" by OSM data, so they
> are derived (I would argue).
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Licence of Facebook's derived road datasets? ODbL?

[Yuri Astrakhan]

Let me get this straight:

* I create a dataset from public data sources, e.g. a list of roads, and
publish it under the Public Domain dedication (i.e. CC0).  (I agree that
MIT is weird here).
* Afterwards, I make a subset of my original data by removing any roads I
found elsewhere, e.g. in a proprietary source.
* And now you are saying that the new _subset_ of my original public domain
data is no longer public domain because I removed values that exist in a
proprietary source?

I think this is taking it a bit too far, but IANAL... You are obviously
welcome to take it to court, but I think it will be a breach of trust if
OSMF would spend donated funds on fighting windmills. If anything, it will
stop any serious organization from ever touching anything related to OSM -
as they would never know what lawsuits might be brought up against them,
thus effectively killing OSM.

I feel there are some members of OSM community that ideologically opposed
to Facebook in general. I can understand that position, but I don't think
it should affect our judgement of the actual contribution, which only makes
our data better. The last thing we would want is for OSM to become a legal
minefield.

On Thu, Nov 14, 2019 at 3:47 PM Mateusz Konieczny 
wrote:

>
>
>
> 14 Nov 2019, 21:38 by r...@technomancy.org:
>
> Facebook provide download dumps of their machine detected roads on a
> country by country basis
>
> IANAL, but as far as i know you are
> 100% right.
>
> Also, is their road detection powered
> by already mapped OSM roads?
> In such case it would be ODBL even
> before substraction of what is in 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] [Tagging] Document personal tags in Proposed_features/ space, User: space, or Tag:/Key: space?

[Yuri Astrakhan]

I agree with Christoph -- every tag used in OSM data must be documented --
otherwise it has near-zero value.. Actually negative value because it
confuses people -- some might want to delete it, but they don't know if it
is useful, so they just leave it there almost indefinitely.

In an ideal world (not limited by the current tooling), the person adding a
new tag should type in an explanation why they are adding it at the same
time it is added.  The tools should also show the user what other similar
tags are available (based on the name and the typed in description), in
case the user is making a mistake and the needed tag already exists.

If we agree on this vision, lets work on achieving that -- we can discuss
implementation details, and I will be happy to participate in that.

On Thu, Aug 15, 2019 at 7:23 AM Christoph Hormann  wrote:

> On Thursday 15 August 2019, Joseph Eisenberg wrote:
> >
> > In contrast, the current text of the wiki page "Any tags you like
> > suggests creating a new tag for bird nests (as an example) with
> > Key:endangered_nest=Siberian_flying_squirrel - besides suggesting
> > using non-standard capitalization in the value, this suggests
> > creating a new Key: / Tag: page directly, rather than using
> > User:username/ or Proposed_features/.
> >
> > Is this a good idea?  Occasionally new wiki pages are created in
> > these standard spaces for tags with only a few uses or no uses in the
> > database.
>
> Yes, IMO it is not only acceptable to document newly invented tags but
> also advisable to do so.  Note however inventing tags in this context
> means actively using them, not theoretical inventions along the lines
> of "I would like mappers to tag things this way therefore i document
> the tag as if it was being used".  Elaborate tagging schemes should be
> discussed before being used and not be invented ad hoc by individual
> mappers.
>
> The reason is - as you mentioned - the "Any tags you like" principle.
> It means you can and should invent new tags for *things no tag exists
> for so far*.  To allow mappers to determine if there is already an
> existing tag for a certain type of feature tags have to be documented.
> Or looking at things the other way round:  If inventing new tags is
> encouraged but it is discouraged to document them in a way that can be
> easily found by other mappers that would massively emphasize tag
> proliferation since mappers will repeatedly invent new and different
> tags for certain things because they are unaware that another mapper
> has already invented a tag for this.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] Overpass API - Fetching countries, their capitals, and their borders

[Yuri Astrakhan]

You can use Sophox to pull this type of information, possibly just not all
at once.

Here's a query that will give you all first level country sub-divisions
(Canada in this case), as well as each province's Captial, Flag image, and
ISO codes.

https://tinyurl.com/y6jowy8v

(this query was modified from one of the examples Sophox has)

On Tue, Aug 13, 2019 at 5:47 PM Léo El Amri via talk 
wrote:

> Hello,
>
> I'm trying to fetch countries, their borders, and their capitals through
> Overpass API, but the server never replies to me (With a timeout:3600
> setting, the server reply with a 502 error after a while).
> I'm only a beginner with this API, so maybe my request is not efficient:
>
> (
>   node[place=city];
>   node[place=town];
> )->.a;
> rel[boundary=administrative][admin_level=2]->.b;
> (
>   node[place=country];
>   node.a[capital=yes];
>   way[boundary=administrative][admin_level=2];
>   .b;
>   .b >;
> )->.o;
> .o out body;
>
> What am I doing wrong ? (Should I use another tool for this purpose ?)
>
> Cordially,
> Léo
>
> ___
> 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] Facebook mapping highways using AI in collaboration with OpenStreetMap

[Yuri Astrakhan]

Also, fully accurate data is a myth, even if we only have 1%
completeness. Once data is beyond a certain size, it is guaranteed to be
wrong, simply because humans always make mistakes and things always become
outdated.  We can only discuss how close we are to the ideal "perfect
accuracy", and what is the best method(s) to get there.  Per above, going
from 1% to 101% completeness certainly gets us closer to the perfect
accuracy, especially as John mentioned, with a mobile device it is easier
to flag some minor mistake than to ignore the whole area because it only
has 1% completeness.

On Mon, Jul 29, 2019 at 1:28 PM john whelan  wrote:

> I agree with Kathleen.  Given that smartphones are more common than
> internet connected computers and it is easier to add or change tags on a
> smartphone than add a long highway at least the locals stand more chance
> this way.
>
> Cheerio John
>
> On Mon, Jul 29, 2019, 1:00 PM Kathleen Lu via talk, <
> talk@openstreetmap.org> wrote:
>
>> On the other hand, if the map of your area is completely blank, it looks
>> very daunting to a new mapper, who may be discouraged and abandon OSM
>> (either as too difficult to improve and as too poor quality to use).
>> The map is constantly changing because roads and other things on the map
>> are changing in the real world. A city might close off a road and then it
>> will become a "bad" street. It's easier to delete a bad street than to add
>> a bunch of streets, especially when you are surveying on foot and don't
>> have a mouse.
>> I personally would much rather have a 101% map than a 1% map.
>>
>> On Mon, Jul 29, 2019 at 9:21 AM Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> wrote:
>>
>>> Re: "OSM map with a one percent of roads is far worse than having 101%
>>> of the roads mapped with the help of AI with 1% of extras, because
>>> fixing that 1% is far less work than adding 99% by hand"
>>>
>>> I'm not certain this is true. It might be very difficult to find the
>>> 1% of incorrectly mapped roads; you don't know where to look, and you
>>> must survey on the ground with GPS, and check each road segment to
>>> find the 1% that actually are blocked by a fence or gate or don't
>>> really go through that clump of trees.
>>>
>>> In contrast, when 99% are missing it's very obvious when looking at
>>> the map data. You still have to survey and add the streets, but it may
>>> actually be faster to get to a complete map of your home neighborhood,
>>> than trying to find 10 bad streets out of 1000 segments in your
>>> neighborhood.
>>>
>>> Finally, when you look at the map and it looks 100% complete, you
>>> won't see the need to start mapping and become a totally addicted
>>> OSMer like you will if your village is only 1% mapped, so we may not
>>> get the new contributors that we need to actual maintain the data that
>>> our robot mappers have added.
>>>
>>> Joseph
>>>
>>> ___
>>> 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] Facebook mapping highways using AI in collaboration with OpenStreetMap

[Yuri Astrakhan]

On Mon, Jul 29, 2019 at 6:19 AM Martin Koppenhoefer 
wrote:

> speaking about risks, having an incomplete network of verified, correct
> roads is probably more useful and less troublesome than an "overcomplete"
> one which also contains non-existent roads (e.g. waterways interpreted as
> roads) or shows connections that aren't there in reality.
>

I think this position should be a bit more nuanced.  Taken to absurdity,
OSM map with a one percent of roads is far worse than having 101% of the
roads mapped with the help of AI with 1% of extras, because fixing that 1%
is far less work than adding 99% by hand.  I'm sure we can find a good
balance between both positions.

Thx!
--Yuri
___
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]

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] 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] 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

Re: [OSM-talk] We're erasing our history in wiki

[Yuri Astrakhan]

If the whole issue is optimizing search results, lets just create an
"Archive" namespace that is not included in search by default.  Moving to
archive is different from deleting because only admins can see deleted
content.

On Mon, Apr 22, 2019 at 4:11 AM Lester Caine  wrote:

> On 22/04/2019 11:45, Ilya Zverev wrote:
> > It’s history.
> Ilya ... it's the same problem we have with with a lot of the historic
> material. Personally I'd prefer to see the history accessible in some
> way, be it the history of the development of a area of mapping data, or
> the history of how we got to a particular style of recording that data.
> The data is in reality not totally lost, all that is missing is some
> general consensus on making it visible when appropriate.
>
> There has been a request for 'namespaces' in the wiki to help manage
> such things as the historic discussions on how tags have evolved and why
> some have been rejected. I'm not sure that it is the appropriate way to
> manage it, but an historic time line view of wiki pages is something
> that would not require 'manual management' and with a switch to display
> or not deleted pages would fill the gap? People investigating a
> particular tagging development could then see the past history of
> related pages.
>
> Doing the same with the map data is somewhat more difficult, but I still
> think it's a development that would replace the need to marry OSM with
> OHM for material that is substantially linked to current live data?
>
> --
> Lester Caine - G8HFL
> -
> Contact - https://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - https://lsces.co.uk
> EnquirySolve - https://enquirysolve.com/
> Model Engineers Digital Workshop - https://medw.co.uk
> Rainbow Digital Media - https://rainbowdigitalmedia.co.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] 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] 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] 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]

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] Dialects of English | Re: iD influencing tagging

[Yuri Astrakhan]

Excellent point Rory, thx. We can already enter tag description in data
items in many English variants, e.g. Patois or Canadian or even Old English
:), and iD editor will automatically get the right one when showing tag
info. There is now a discussion on how to region-limit tags too (this is
different from "language-limiting" we have now, that needs to go away).

* a 2 min video on how to add descriptions -
https://wiki.openstreetmap.org/wiki/Data_items
* amenity=college data item https://wiki.openstreetmap.org/wiki/Item:Q4763


On Wed, Apr 10, 2019 at 5:24 AM Rory McCann  wrote:

>
> A better example might be "college", which has different meanings in
> different dialects of English, or "gallon" or "football"
>
> I don't think there is a solution this, except better localization of
> software. Or we all just switch to Esperanto or Irish or something.
>
> If you want real fun, just talk about "tabling an agenda item" 
>
> On 08/04/2019 18:32, Yuri Astrakhan wrote:
> > 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
> > mailto:dieterdre...@gmail.com>> wrote:
> >
> >
> >
> > sent from a phone
> >
> >  > On 7. Apr 2019, at 22:23, Yuri Astrakhan  > <mailto:yuriastrak...@gmail.com>> 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
> >
>
>
___
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] 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] 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] 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
> 

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] 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] 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]

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]

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: [Talk-us] More-complex wiki pages are spitting up Lua errors

[Yuri Astrakhan]

Yep, that's probably because Tom has merged the settings change :)
Thanks for reporting it!

On Mon, Sep 24, 2018 at 1:06 PM OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> Well, I'm no longer seeing the Lua errors I saw, so "caches cleared" (all
> the way down) and the problem seems to be "fixed" now.
>
> Steve
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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] 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 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: [Talk-us] More-complex wiki pages are spitting up Lua errors

[Yuri Astrakhan]

I think the Lua crashing is related to this discussion:

http://www.mediawiki.org/wiki/Thread:Extension_talk:Scribunto/Lua_error:_Internal_error:_The_interpreter_has_terminated_with_signal_%2224%22
.

> You set $wgScribuntoEngineConf['luastandalone']['cpuLimit'] too low.
Either raise it or unset it.

Someone said that it was not set, but they raised it and it worked.  I
don't know what's the value being used by default
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[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] 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] 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] 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

[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] 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] 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] 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]

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. 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]

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]

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]

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] 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] 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]

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] 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 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]

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]

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]

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] 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] 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] 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:
>>
>>

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

[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]

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] 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] 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

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] 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]

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] 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]

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]

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] 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] 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] 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 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