Re: [OSM-talk] [OSM-talk-ie] Mapping of footpaths and cycleways

[Dave Foley]

Personally I’m against separate mapping for the following reasons:


  1.  A highway/road shouldn’t be considered only for motor vehicles by default.
  2.  I don’t see any routing advantages to mapping it separately. If anything 
it makes the better cycleways, like the Dun Laoghaire coastal route, harder to 
find.
  3.  The area in question was around Adamstown - 
https://www.openstreetmap.org/#map=18/53.33068/-6.45455, it was hard to see 
other features with three bridges, when in reality there is only one. With a 
Garmin device it was worse.
  4.  Some of the paths and cycleways tagged as part of the highway precede the 
individual paths.

On a different point the other user said he checked with the OSM Telegram 
account and people said it was ok to map separately. I don’t think it’s great 
to have two different places to discuss issues, or at the very least publish 
what was decided on the wiki so that people know what decisions were made.

Dafo

Sent from Mail for Windows


From: Colm Moore 
Sent: Friday, February 10, 2023 4:18:12 PM
To: Donal Hunt ; davefo...@hotmail.com 

Subject: Re: [OSM-talk-ie] Mapping of footpaths and cycleways

Hi,

This is off-list again.

I'm preparing some notes. Can just the two of you send me some reasons to map / 
not map sidewalks?

Thank you

Colm

---
Never doubt that a small group of thoughtful, committed citizens can change the 
world. Indeed, it is the only thing that ever has. Margaret Mead


From: Colm Moore 
Sent: 10 February 2023 14:10
To: Donal Hunt ; davefo...@hotmail.com 

Subject: Re: [OSM-talk-ie] Mapping of footpaths and cycleways

Hi,

This is off-list.

It happens in places. Sometimes it is messy, sometimes it is trying to solve 
complicated situations.

I'll come back with a fuller answer later.

Colm

---
Never doubt that a small group of thoughtful, committed citizens can change the 
world. Indeed, it is the only thing that ever has. Margaret Mead


From: Donal Hunt 
Sent: 10 February 2023 13:28
To: Discussion of OpenStreetMap in Ireland ; 
colmmoor...@hotmail.com 
Subject: Re: [OSM-talk-ie] Mapping of footpaths and cycleways

Hi Dave!

Thanks for raising this.

These are the type of quality issues we are hoping for the Quality Working 
Group (yet to be formally launched) to take a role in. I've CCed Colm who has 
worked on lots of quality issues over time and may be able to contribute to 
this discussion.

Do we know how widespread the issue is? There have been a few academic efforts 
in small geographic areas to map paths separately to capture access data.

In relation to how to proceed from here: with the increased funding for walking 
and cycling during the current government, there is a lot of interest in 
capturing data of completed projects, etc. I personally think that separate 
mapping makes sense if there are people willing to put the work in to capture 
and maintain it. There are lots of corner cases involving infrastructure being 
installed in a manner which results in separate mapping making sense.

I would suggest the following next steps:
- Discussion on best practice / community consensus on how to map (this email 
thread)
- Update of wiki documentation
- Data analysis to understand where these issues exist
- Cleanup tasks (via task manager)

Thoughts? Comments?

Donal

On Fri 10 Feb 2023, 13:07 Dave Foley, 
mailto:davefo...@hotmail.com>> wrote:
Hi,

An issue came up with the mapping of paths next to roads. If recall correctly 
it was on the wiki (or possibly somewhere else) that it was agreed to only map 
paths that were not beside a road or where there was cycleway running 
counter-flow to traffic. At some point people started mapping paths 
individually and now we have a mix of where the ‘sidewalk’ is mapped in the 
highway tag and some individual paths. Admittedly the wiki allows for both, 
https://wiki.openstreetmap.org/wiki/Sidewalks
 , but I don’t remember a discussion on changing to individual path mapping.

So if it was discussed and a decision was made can the Ireland wiki page be 
updated with this? If there is no consensus currently then I think it would 
better to reach one now.

Dafo

Sent from 

Re: [OSM-talk] OSM and Google

[Niels Elgaard Larsen]

Jiri Vlasak:

On Mon, Dec 14, 2020 at 07:16:14PM +, Tom Hughes via talk wrote:

No it couldn't - the google problem he refers to was with
their authentication service not their DNS service.


So maybe he use Google as third party to login to OpenStreetMap?


No I did not. Only OSM.

But I did hear from another mapper that had the same problem, that the issue 
disappeared after he unchecked the "Use OAuth for all requests to 
https://api.openstreetmap.org/api; box.




--
Niels Elgaard Larsen

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

Re: [OSM-talk] OSM and Google

[Mateusz Konieczny via talk]

Dec 18, 2020, 18:55 by jiri.huba...@gmail.com:

> On Mon, Dec 14, 2020 at 07:16:14PM +, Tom Hughes via talk wrote:
>
>> No it couldn't - the google problem he refers to was with
>> their authentication service not their DNS service.
>>
>
> So maybe he use Google as third party to login to OpenStreetMap?
>
OpenStreetMap had outage that was more widespread than not
working sign-in using Google account.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and Google

[Jiri Vlasak]

On Mon, Dec 14, 2020 at 07:16:14PM +, Tom Hughes via talk wrote:
> No it couldn't - the google problem he refers to was with
> their authentication service not their DNS service.

So maybe he use Google as third party to login to OpenStreetMap?

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

Re: [OSM-talk] OSM and Google

[Tom Hughes via talk]

No it couldn't - the google problem he refers to was with
their authentication service not their DNS service.

Tom

On 14/12/2020 19:10, James wrote:

are you using 8.8.8.8 or 4.4.4.4 as a dns? could explain it.

On Mon., Dec. 14, 2020, 1:58 p.m. Niels Elgaard Larsen, > wrote:


Google services was down for an hour today. I noticed that at the
same time I could
not push my edits with JOSM due to "internal server error"

Was that a coincidence or do we somehow depend on Google?



-- 
Niels Elgaard Larsen


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



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




--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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

Re: [OSM-talk] OSM and Google

[James]

are you using 8.8.8.8 or 4.4.4.4 as a dns? could explain it.

On Mon., Dec. 14, 2020, 1:58 p.m. Niels Elgaard Larsen, 
wrote:

> Google services was down for an hour today. I noticed that at the same
> time I could
> not push my edits with JOSM due to "internal server error"
>
> Was that a coincidence or do we somehow depend on Google?
>
>
>
> --
> Niels Elgaard Larsen
>
> ___
> 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 Google

[Tom Hughes via talk]

On 14/12/2020 18:54, Niels Elgaard Larsen wrote:

Google services was down for an hour today. I noticed that at the same 
time I could not push my edits with JOSM due to "internal server error"


Was that a coincidence or do we somehow depend on Google?


It was a coincidence.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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

[OSM-talk] OSM and Google

[Niels Elgaard Larsen]

Google services was down for an hour today. I noticed that at the same time I could 
not push my edits with JOSM due to "internal server error"


Was that a coincidence or do we somehow depend on Google?



--
Niels Elgaard Larsen

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

[OSM-talk] OSM Software Watchlist

[wambacher]

She is back ;)

https://wambachers-osm.website/SoftwareWatchlist.html

Weekly updates are usually posted on Saturday in the German Forum 
https://forum.openstreetmap.org/viewtopic.php?pid=809928#p809928. (*)


Tips for new software are welcome. Lost the overview a bit.

Greetings
Walter aka wambacher

--
My projects:

OSM Software Watchlist 

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

[OSM-talk] OSM Software Watchlist

[wambacher]

Sie ist wieder da smile

https://wambachers-osm.website/SoftwareWatchlist.html

Wöchentliche Updates werden in der Regel am Samstag im Deuschen Forum 
https://forum.openstreetmap.org/viewtopic.php?pid=809928#p809928 
gepostet. (*)


Tipps für neue Software sind herzlich willkommen. Hab ein wenig den 
Überblick verloren.


Gruss
walter

(*) Ja, im Forum. Auf talk-de gab es ja einen fürchterlichen Aufstand, 
als ich die wöchentlichen Updates hier gepostet hatte.


--

My projects:

OSM Software Watchlist 

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

Re: [OSM-talk] OSM ↔ Wikidata - new tool encouraging automated / mechanical addition of wikidata tags

[Mateusz Konieczny via talk]

I used it with manual review of tagged objects and with verification of every 
match.

It is necessary as many matches are spurious/invalid (see bug reports at
https://github.com/EdwardBetts/osm-wikidata/issues ). 

Note that it is not criticism of the tool - some false positives will be always 
present.

Not sure what can be done on tool side. I would encourage reverting any edits 
of people who used this tool without real review of what is added, but not sure 
what more
can be done. Except https://github.com/EdwardBetts/osm-wikidata/issues/555 that
was just partially fixed (there is now "show all tags" tool)

Maybe remind in OSM Wiki page that blind adding without verification is not 
helpful at all?

Oct 8, 2020, 23:27 by joseph.eisenb...@gmail.com:

> https://wiki.openstreetmap.org/wiki/OSM_↔_Wikidata 
> 
>
> According to the new wiki entry, OSM ↔ Wikidata is a tool that is supposed to 
> automatically find all wikidata entries for OpenStreetMap features in a 
> certain area, and make it easy to add the tags semi-automatically.
>
> This seems like it will invite violations of the Automated Edits policy (> 
> https://wiki.openstreetmap.org/wiki/Automated_edits> )
>
> "OSM ↔ Wikidata (osm-wikidata-link) is a web based tool that can be used to 
> semi-automatically add the Wikidata tag to an OpenStreetMap object. It is 
> developed by  Edward Betts (Edward) (and others github contributors) in 
> Python and web technologies (HTML/CSS/JS)." 
>
> "> This tool displays results in tabs:
> Match candidates: display the potential OSM objects matching Wikidata item
> This is the main tab. It allows user to match and add > wikidata 
> > =*>  tags to OSM objects
> Already tagged: display the OSM object and his > wikidata 
> > =*>  key
> No match: display Wikidata item without match in OSM
> This tab allows user to edit OSM and add the > wikidata 
> > =*>  tag manually
> Wikidata query: display the Wikidata SPARQL query."
>
> What should we ask the developers to do so that this tool won't be 
> encouraging every to violate the Automated Edits policy?
>
> - Joseph Eisenberg
>

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

[OSM-talk] OSM ↔ Wikidata - new tool encouraging automated / mechanical addition of wikidata tags

[Joseph Eisenberg]

https://wiki.openstreetmap.org/wiki/OSM_↔_Wikidata

According to the new wiki entry, OSM ↔ Wikidata is a tool that is supposed
to automatically find all wikidata entries for OpenStreetMap features in a
certain area, and make it easy to add the tags semi-automatically.

This seems like it will invite violations of the Automated Edits policy (
https://wiki.openstreetmap.org/wiki/Automated_edits)

"OSM ↔ Wikidata (osm-wikidata-link) is a web based tool that can be used to
semi-automatically add the Wikidata tag to an OpenStreetMap object. It is
developed by  Edward Betts (Edward) (and others github contributors) in
Python and web technologies (HTML/CSS/JS)."

"This tool displays results in tabs:

   1. Match candidates: display the potential OSM objects matching Wikidata
   item
  - This is the main tab. It allows user to match and add wikidata
  =* tags to OSM
  objects
   2. Already tagged: display the OSM object and his wikidata
   =* key
   3. No match: display Wikidata item without match in OSM
  - This tab allows user to edit OSM and add the wikidata
  =* tag manually
   4. Wikidata query: display the Wikidata SPARQL query."


What should we ask the developers to do so that this tool won't be
encouraging every to violate the Automated Edits policy?

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

[OSM-talk] OSM Carto stylesheet vs Release osm2pgsql 1.3.0

[Lynn W. Deffenbaugh (Mr)]

On 7/28/2020 4:39 AM, Sarah Hoffmann wrote:

Further changes:

  * The pgsql output now looks for lua script relative to the
|style.json| file.
This is a breaking change. Users might have to change the file
names of
their lua scripts in the style files.

Does anyone know if changes need to be made to the OpenStreetMap Carto 
stylesheet or is it already compatible with this breaking change?


I confess that I run a planet-wide tile server with the OSM Carto 
stylesheet and using osm2pgsql to apply updates but I have NO idea just 
what is in the stylesheet and how it all works with osm2pgsql.  I've put 
in the documented commands and it "just works", at least pending this 
question.


Lynn (D)

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

Re: [OSM-talk] OSM Carto not updating

[Lynn W. Deffenbaugh (Mr)]

https://www.openstreetmap.org/relation/971999

On 6/28/2020 8:23 AM, Ture Pålsson wrote:



27 juni 2020 kl. 17:20 skrev Marc M. :

Hello,

Le 27.06.20 à 17:04, ET Commands a écrit :

Is something wrong with the OSM Carto servers?

one diff freeze the update
sequenceNumber=4082799
timestamp=2020-06-26T19:17:02Z
ppl on #osm-dev are working on this.

Does anyone have the osm ID of the geometry that tripped things up? Seems like 
a good test case. :-)



___
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 Carto not updating

[Marc M.]

Le 28.06.20 à 14:23, Ture Pålsson a écrit :
>> 27 juni 2020 kl. 17:20 skrev Marc M. :
>> Le 27.06.20 à 17:04, ET Commands a écrit :
>>> Is something wrong with the OSM Carto servers?
>> one diff freeze the update
>> sequenceNumber=4082799
>> timestamp=2020-06-26T19:17:02Z
>> ppl on #osm-dev are working on this.
> Does anyone have the osm ID of the geometry that tripped things up? Seems 
> like a good test case. :-)

tmp fix target 3 relations with multiples errors (self-crossing outer)
https://overpass-turbo.eu/s/Vxd

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

Re: [OSM-talk] OSM Carto not updating

[Ture Pålsson]

> 27 juni 2020 kl. 17:20 skrev Marc M. :
> 
> Hello,
> 
> Le 27.06.20 à 17:04, ET Commands a écrit :
>> Is something wrong with the OSM Carto servers?
> 
> one diff freeze the update
> sequenceNumber=4082799
> timestamp=2020-06-26T19:17:02Z
> ppl on #osm-dev are working on this.

Does anyone have the osm ID of the geometry that tripped things up? Seems like 
a good test case. :-)



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

Re: [OSM-talk] OSM Carto not updating

[Marc M.]

Le 28.06.20 à 00:25, Lynn W. Deffenbaugh (Mr) a écrit :
> Where is #osm-dev? 

on irc://irc.oftc.net/osm-dev

info about irc/web/mnatrix client
https://wiki.openstreetmap.org/wiki/IRC

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

Re: [OSM-talk] OSM Carto not updating

[Sarah Hoffmann]

Hi,

short update on the issue: libosmium has just made a new release
that fixes the issue: https://github.com/osmcode/libosmium/releases/tag/v2.15.6

osm2pgsql and Nominatim will get new bug-fix releases with the
new libosmium version by today or tomorrow.

You can already download the new libosmium and build osm2pgsql
against that to get a fixed version.

If that is not an option, you can get your installation unstuck for now
by patching the configuration to ignore the offending Klamath forst.

For openstreetmap-carto, add the following patch to your
openstreetmap-carto.lua file:
https://gist.github.com/lonvia/ab7db4156bbfbcf8ebe1ba8185c2e66c

For Nominatim, you need to skip the relation in the import style
file configured through the CONST_Import_Style variable. This
would be settings/import-full.style per default. You need to add
the lines as in this patch:
https://git.openstreetmap.org/nominatim.git/commitdiff/f9ba2af
(careful, the osm.org installation uses import-extratags.style.
 You must apply the patch to the style file you use. Just make
 sure the lines are added at the top of the file.)

In both cases: after you have applied the patch, kill osm2pgsql
and then restart your update process as usual.

Kind regards

Sarah


On Sat, Jun 27, 2020 at 06:25:11PM -0400, Lynn W. Deffenbaugh (Mr) wrote:
> Where is #osm-dev?  I'd like to listen in as my updates are also stalling
> with osm2pgsql ramping up to 100% while processing relations.
> 
> Lynn (D) - Running a planet-wide tile server with updates...  (or trying
> to!)
> 
> On 6/27/2020 11:20 AM, Marc M. wrote:
> > Hello,
> > 
> > Le 27.06.20 à 17:04, ET Commands a écrit :
> > > Is something wrong with the OSM Carto servers?
> > one diff freeze the update
> > sequenceNumber=4082799
> > timestamp=2020-06-26T19:17:02Z
> > ppl on #osm-dev are working on this.
> > 
> > Regards,
> > Marc
> > 
> > ___
> > 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 Carto not updating

[Lynn W. Deffenbaugh (Mr)]

Where is #osm-dev?  I'd like to listen in as my updates are also 
stalling with osm2pgsql ramping up to 100% while processing relations.


Lynn (D) - Running a planet-wide tile server with updates...  (or trying 
to!)


On 6/27/2020 11:20 AM, Marc M. wrote:

Hello,

Le 27.06.20 à 17:04, ET Commands a écrit :

Is something wrong with the OSM Carto servers?

one diff freeze the update
sequenceNumber=4082799
timestamp=2020-06-26T19:17:02Z
ppl on #osm-dev are working on this.

Regards,
Marc

___
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 Carto not updating

[Marc M.]

Hello,

Le 27.06.20 à 17:04, ET Commands a écrit :
> Is something wrong with the OSM Carto servers?

one diff freeze the update
sequenceNumber=4082799
timestamp=2020-06-26T19:17:02Z
ppl on #osm-dev are working on this.

Regards,
Marc

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

[OSM-talk] OSM Carto not updating

[ET Commands]

Is something wrong with the OSM Carto servers?  I have uploaded several 
changesets in the last few hours, and none of them are showing up in OSM 
Carto.


Mark


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

Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

[Bryce Cogswell via talk]

> On May 28, 2020, at 9:38 AM, Andy Townsend wrote:
> 
> It sounds like he's learnt something really useful about the computer 
> representation of written characters!

This page generates all manner of font variations for a name:
http://qaz.wtf/u/convert.cgi?text=OpenStreetMap

퐎퐩퐞퐧퐒퐭퐫퐞퐞퐭퐌퐚퐩
핺햕햊햓핾햙햗햊햊햙핸햆햕
푶풑풆풏푺풕풓풆풆풕푴풂풑
퓞퓹퓮퓷퓢퓽퓻퓮퓮퓽퓜퓪퓹
핆핡핖핟핊핥핣핖핖핥필핒핡
etc.

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

Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

[Andy Townsend]

On 28/05/2020 17:29, mbranco2 wrote:
햒햆햘햙햗햔  has all to do with mastro, because it's the surname of a 
student in an Italian high school where I'm teaching  OSM  :-)


It sounds like he's learnt something really useful about the computer 
representation of written characters!


Best Regards,

Andy


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

Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

[mbranco2]

햒햆햘햙햗햔  has all to do with mastro, because it's the surname of a
student in an Italian high school where I'm teaching  OSM  :-)
His classroom is participating in a mapathon for UN (
https://tasks.teachosm.org/project/998), commenting changeset withs
#AAvogadroONU.
When I asked him how he registered in OSM, he told me that he likes gothic
font, and in every social he registered in that way (writing his surname in
gothic with a wordprocessor, and copying/pasting it in the registering form.

Surely I agree everyone in the world must be able to register using
characters of his language, but I supposed that the sequence to  change the
font character is something different from characters in other alphabets
(sorry, I'm not an expert of character encoding, maybe this is not true).
Or maybe we could use nicknames  also bolded, underlined, ...

Il giorno gio 28 mag 2020 alle ore 15:30 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

>
>
> sent from a phone
>
> On 28. May 2020, at 15:08, mbranco2  wrote:
>
> I was surprised finding an OSM username written in gothic characters: I'm
> not sure if this mailing list could show such font, the
> nickname is 햒햆햘햙햗햔 ("mastro" in normal characters).
> The problem is that, if you want to access this user profile, you've to
> copy and paste his name written with such font, searching with
> osm.org/user/mastro give no results.
>
> Isn't this an anomaly?
>
>
>
> it’s normal, we allow unicode characters for usernames, and there is no
> tolerant “search“ behind osm.org/user/username
> AGAIK it requires the exact string (maybe whitespace trimmed) that the
> mapper has used for registering.
> If the user had written in a different script which you do not have
> available on your keyboard you would have had equally to use copy+paste (or
> click on a link to the user).
>
>  햒햆햘햙햗햔 has nothing to do with mastro, although it might look as if
> it has.
>
> Cheers Martin
>
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

[Steve Friedl]

> If there is any real problem here, it could be with people using names that 
> look like the names of other community members (but technically are 
> different) for abusive scopes

Can I be Ṡtereo ? :-)

-Original Message-
From: Martin Koppenhoefer  
Sent: Thursday, May 28, 2020 8:38 AM
To: Oleksiy Muzalyev 
Cc: talk@openstreetmap.org
Subject: Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)



sent from a phone

> On 28. May 2020, at 17:20, Oleksiy Muzalyev  
> wrote:
> 
> Practically all people in Russia studied a foreign language within the 
> compulsory education system. ... I am sure that typing several Latin letters 
> would not be a challenge.
> 
> Besides in such disciplines as mathematics or chemistry the Latin letters are 
> being used widely for variables in formulas, etc.
> Customarily, a keyboard with the Russian layout has got also the Latin 
> letters on the keys (buttons) [1].
> 
> I do not know exactly about Japan and China, but I guess that it is about the 
> same there too.


I think the question is not so much whether someone not usually writing in 
latin characters will be able to do it, but more whether a name written in 
latin is suitable for them to identify with. IMHO there is great benefit in 
allowing unicode names, and very little problem with people using “strange 
looking” characters to mean something in different than what the characters are 
originally intended for.

If there is any real problem here, it could be with people using names that 
look like the names of other community members (but technically are different) 
for abusive scopes. This shouldn’t be tolerated of course, and would be 
individually reacted to by the admins, if it is detected.

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] OSM nicknames are Unicode characters? (not Ascii?)

[Martin Koppenhoefer]

sent from a phone

> On 28. May 2020, at 17:20, Oleksiy Muzalyev  
> wrote:
> 
> Practically all people in Russia studied a foreign language within the 
> compulsory education system. ... I am sure that typing several Latin letters 
> would not be a challenge.
> 
> Besides in such disciplines as mathematics or chemistry the Latin letters are 
> being used widely for variables in formulas, etc.
> Customarily, a keyboard with the Russian layout has got also the Latin 
> letters on the keys (buttons) [1].
> 
> I do not know exactly about Japan and China, but I guess that it is about the 
> same there too.


I think the question is not so much whether someone not usually writing in 
latin characters will be able to do it, but more whether a name written in 
latin is suitable for them to identify with. IMHO there is great benefit in 
allowing unicode names, and very little problem with people using “strange 
looking” characters to mean something in different than what the characters are 
originally intended for.

If there is any real problem here, it could be with people using names that 
look like the names of other community members (but technically are different) 
for abusive scopes. This shouldn’t be tolerated of course, and would be 
individually reacted to by the admins, if it is detected.

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

Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

[Oleksiy Muzalyev]

Practically all people in Russia studied a foreign language within the 
compulsory education system. Usually it is English, French, or German.
How well they may know the language is debatable, however I am sure that 
typing several Latin letters would not be a challenge.


Besides in such disciplines as mathematics or chemistry the Latin 
letters are being used widely for variables in formulas, etc.
Customarily, a keyboard with the Russian layout has got also the Latin 
letters on the keys (buttons) [1].


I do not know exactly about Japan and China, but I guess that it is 
about the same there too.


[1] 
https://www.pngfind.com/pngs/m/326-3264221_russian-keyboard-layout-norwegian-keyboard-layout-windows-hd.png


On 28-May-20 15:28, Maarten Deen wrote:
I'm sure this is a feature that's very helpful for everyone not 
writing in latin script (Russia, China, Japan, etc).




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

Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

[Roland Olbricht]

See 
https://www.openstreetmap.org/user/%F0%9D%96%92%F0%9D%96%86%F0%9D%96%98%F0%9D%96%99%F0%9D%96%97%F0%9D%96%94
URL-Percent-Encoding works fine, so does the involved XML. It is
solely a problem of UX software.

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

Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

[Hartmut Holzgraefe]

On 2020-05-28 15:27, Mateusz Konieczny via talk wrote:
> See case of anyone from Russia or Łukasz from Poland.

or people from Germany who were not as lucky as me who had
the 'ä' in the family name converted to ASCII-friendly 'ae'
some generations ago already (due to a transmission error
at the town hall, nobody would even have known about ASCII
back in those days ...)

-- 
hartmut


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

Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

[Mateusz Konieczny via talk]

May 28, 2020, 15:38 by martin.zd...@freemap.sk:

> On Thu, May 28, 2020 at 3:34 PM Martin Koppenhoefer <> 
> dieterdre...@gmail.com> > wrote:
>
>>
>>  햒햆햘햙햗햔 has nothing to do with mastro, although it might look as if it has.
>>
>
> Google has different opinion ;-)
>
"햒햆햘햙햗햔 has nothing to do with mastro" seems to be something unique to Unicode

https://en.wikipedia.org/wiki/Fraktur#Fraktur_in_Unicode

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

Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

[Martin Ždila]

On Thu, May 28, 2020 at 3:34 PM Martin Koppenhoefer 
wrote:

>
>  햒햆햘햙햗햔 has nothing to do with mastro, although it might look as if
> it has.
>

Google has different opinion ;-)

-- 
Martin Ždila
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

[Martin Koppenhoefer]

sent from a phone

> On 28. May 2020, at 15:08, mbranco2  wrote:
> 
> I was surprised finding an OSM username written in gothic characters: I'm not 
> sure if this mailing list could show such font, the nickname is 햒햆햘햙햗햔 
> ("mastro" in normal characters).
> The problem is that, if you want to access this user profile, you've to copy 
> and paste his name written with such font, searching with osm.org/user/mastro 
> give no results.
> 
> Isn't this an anomaly?


it’s normal, we allow unicode characters for usernames, and there is no 
tolerant “search“ behind osm.org/user/username 
AGAIK it requires the exact string (maybe whitespace trimmed) that the mapper 
has used for registering.
If the user had written in a different script which you do not have available 
on your keyboard you would have had equally to use copy+paste (or click on a 
link to the user).

 햒햆햘햙햗햔 has nothing to do with mastro, although it might look as if it has.

Cheers Martin 



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

Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

[Tom Hughes via talk]

On 28/05/2020 14:02, mbranco2 wrote:

I was surprised finding an OSM username written in gothic characters: 
I'm not sure if this mailing list could show such font, the 
nickname is 햒햆햘햙햗햔 ("mastro" in normal characters).
The problem is that, if you want to access this user profile, you've to 
copy and paste his name written with such font, searching with 
osm.org/user/mastro  give no results.


Isn't this an anomaly?



So we shouldn't allow people who don't use the latin
alphabet to register using names in their native language?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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

Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

[Mateusz Konieczny via talk]

See case of anyone from Russia or Łukasz from Poland.

Or people from China/Japan.

While banning some characters may be reasonable it is complex,
and unlikely to be very important.


May 28, 2020, 15:02 by mbran...@gmail.com:

> Hallo,
> I was surprised finding an OSM username written in gothic characters: I'm not 
> sure if this mailing list could show such font, the nickname is 햒햆햘햙햗햔 
> ("mastro" in normal characters).
> The problem is that, if you want to access this user profile, you've to copy 
> and paste his name written with such font, searching with > 
> osm.org/user/mastro >  give no results.
>
> Isn't this an anomaly?
>

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

Re: [OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

[Maarten Deen]

On 2020-05-28 15:02, mbranco2 wrote:

Hallo,
I was surprised finding an OSM username written in gothic characters:
I'm not sure if this mailing list could show such font, the nickname
is 햒햆햘햙햗햔 ("mastro" in normal characters).
The problem is that, if you want to access this user profile, you've
to copy and paste his name written with such font, searching with
osm.org/user/mastro [1] give no results.

Isn't this an anomaly?


I'm sure this is a feature that's very helpful for everyone not writing 
in latin script (Russia, China, Japan, etc). I'm sure there are many 
users that have their name written in Cyrillic or Hanzi or Kanji but I 
can't give examples because I can't enter those letters.

I won't call it an anomaly but an inconvenience.

Regards,
Maarten

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

[OSM-talk] OSM nicknames are Unicode characters? (not Ascii?)

[mbranco2]

Hallo,
I was surprised finding an OSM username written in gothic characters: I'm
not sure if this mailing list could show such font, the
nickname is 햒햆햘햙햗햔 ("mastro" in normal characters).
The problem is that, if you want to access this user profile, you've to
copy and paste his name written with such font, searching with
osm.org/user/mastro give no results.

Isn't this an anomaly?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OSM Foundation’s Call for Microgrant Applications

[Clifford Snow]

In case you missed this announcement, I'm reposting it on talk-us mailing
list.


2020 will be the first year that the OSM Foundation operates the new
microgrants project. In the coming weeks, we hope to hear from you about a
bold, community-driven, and impactive OpenStreetMap project idea that will
benefit from a microgrant of up to 5000 euros. We welcome a broad range of
projects, with the minimum requirement being a clear connection to
OpenStreetMap.

What is a microgrant ? In our
case, it is a modest amount of funds awarded to applicants in order to fund
direct expenses of a project. For an idea of successful projects, you can
take a look at the Humanitarian OpenStreetMap Team’s 2019 microgrant
awardees
.
Keep in mind that the OSMF has a wider focus than the humanitarian sector,
spanning our global community, and welcomes applications with any focus
that relates to OpenStreetMap. We particularly encourage applicants to
consider the core values from the OSMF’s mission statement
and how any
microgrant work can incorporate them.

The OSMF Microgrant Program focuses on simple grant proposals, and we will
swiftly decide on what to fund. Our goal is to avoid a complicated and long
application and decision process. You should submit a brief and concise
proposal, and we plan to quickly announce the awardees.

We encourage submissions from individuals, groups, and organizations who
have a clear idea they want to pursue. Each project should be completed
within 12 months of the microgrant being awarded this spring. Microgrants
are open to all OSMF members, and can be submitted in any language. If you
are not yet a member of OSMF then you can apply to join
 up until the time you submit a microgrant
application, and be eligible for an award. Please note there is a fee
waiver program that may allow you to join the OSMF at no cost.


In light of the ongoing health crisis regarding COVID19, we will not be
awarding microgrants for projects which require offline group gatherings
and in person meetings, although these ideas are certainly valuable for
future rounds.

Funding can be used for a variety of purposes. You may need tools and
supplies for mapping activity, funds for training materials, technology
expenses for a series of virtual mapathons, prizes for an online coding,
mapping, or writing contest, and many more examples. Please embrace your
own creativity and not feel limited by the range of examples.


We encourage you to consult with your local OpenStreetMap community when
planning a microgrant application, and make sure you adhere to community
guidelines in the scope of the project. If accepted for a microgrant, you
will be responsible for reporting progress, signing a grant agreement, and
making sure to follow the detailed microgrant rules
. It is
strongly suggested that your project uses the funding to enable volunteer
work to have a wider and stronger impact than it would without funding.

The call for microgrants will open on April 19th, 2020 and we will continue
to accept applications through May 10th, 2020. In order to submit,  visit
the OSM Wiki page
 and
click on “Start your application”

to enter the template. When this is complete, send a message to microgrants
at osmfoundation.org. We also encourage sharing your application on
osmf-talk when it is submitted. If you need help with the submission
process, please feel free to contact the Microgrants Committee for help. If
you don’t have enough time to prepare your plan and application, please
consider submitting it in a possible future round of microgrants.

Once the submission period closes on May 10th, we invite the community to
review the complete list of submissions and provide feedback on the wiki
page. We also will accept feedback by email to microgrants at
osmfoundation.org and via osmf-talk.

Complete timeline:

   -

   April 19: call for microgrant applications opens
   -

   May 10: final date for submission (23:59 Pacific Time Zone, USA).
   -

   May 10-TBD: community feedback period
   -

   Late May: announcement of awards


For more details, see the complete rules and guidelines on the OSM wiki
 and
contact us at microgrants at osmfoundation.org with any questions. This is
the first time the OSMF is sponsoring such an activity, and we look forward
to learning together about how this benefits our community and how to build
a transparent, effective, and inclusive microgrants program for everyone
involved. We are grateful for the opportunity 

Re: [OSM-talk] OSM is not the place for dissemination of authoritative data sets

[Andy Townsend]

On 20/03/2020 19:00, Mikel Maron wrote:

   But this thread is from Facebook trying to change that. To side step imports.

No they're not. It's a couple sections in a blog post that is being wildly 
misinterpreted.


It's perhaps worth remembering how we got here:

https://news.ycombinator.com/item?id=17856687

describes Facebook's initial engagement with OpenStreetMap. Apparently " 
It ended up not being so bad however. The entirety of the bad edits were 
reverted in a few minutes with oversight from the head of the OSM data 
working group".  I was part of the "bucket and shovel" reaction to the 
pile of excrement that Facebook dropped on Egypt there, and those 
evenings are ones that I won't get back.


It appears to be only because their previous undocumented import 
attempts were reverted, and they received pushback from OSM mappers 
after other edits elsewhere such as 
https://forum.openstreetmap.org/viewtopic.php?id=63456 that they are 
trying this new strategy.


That's not to say that using "many eyes" to sanity-check "AI"-detected 
stuff and to prompt human mappers to add things that they can see but 
otherwise might not is necessarily a bad thing - it isn't, provided the 
human mappers are in control and familiar with the process* and likely 
quality of the data** that it is suggested that they add, and familiar 
with the area into which they are adding stuff so that they can avoid 
adding (e.g.) walls as roads (in the Egypt example) or crop tramlines as 
roads (via Rapid).


However it _is_ true that Facebook have a history of trying to "side 
step imports" (actually, worse than that).


Best Regards,

Andy

(from OSM's Data Working Group, but writing here in a personal capacity)

* I've not seen it documented how anyone can understand "why xyz was 
detected here" - what source data was used, what alorithm, etc.


** we've seen examples in the US where Rapid-added stuff has been 
voluntarily deleted by the mappers who added it because the quality was 
rubbish.  Issues include offsets in the source data, poor quality of MS 
building footprints in some areas in addition to the "misdetections" 
already mentioned.





___
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

[Mikel Maron]

> Today's blog posts are the press releases of past years. It would have been 
>quite possible to run it past the responsible organs of the organisation they 
>were writing about, as it would have been customary in earlier days.

Good enough idea, but I have seen very few or even no examples of someone 
asking OSMF about a PR/blog beforehand, nor the OSMF asking for that. Not a bad 
idea to change expectations around this.

-Mikel

* Mikel Maron * +14152835207 @mikel s:mikelmaron






On Friday, March 20, 2020, 04:43:28 PM EDT, Simon Poole  wrote: 






Am 20.03.2020 um 20:00 schrieb Mikel Maron:
>>   But this thread is from Facebook trying to change that. To side step 
>> imports.
> No they're not. It's a couple sections in a blog post that is being wildly 
> misinterpreted.

Today's blog posts are the press releases of past years. It would have
been quite possible to run it past the responsible organs of the
organisation they were writing about, as it would have been customary in
earlier days.

Simon


>
> * Mikel Maron * +14152835207 @mikel s:mikelmaron
>
>
>
>
>
>
> On Friday, March 20, 2020, 02:18:54 PM EDT, Rory McCann 
>  wrote: 
>
>
>
>
>
> On 19/03/2020 20:15, Mikel Maron wrote:
>
>> This whole thread is blown out of proportion, and rehashing old 
>> theoretical debates about imports that are more or less resolved in 
>> practice.
>
> Yes, we have an import guideline. But this thread is from Facebook 
> trying to change that. To side step imports.
>
> BTW the Etiqutte guidelines require you to assume all people here are 
> operating in good faith 

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

[Simon Poole]

Am 20.03.2020 um 20:00 schrieb Mikel Maron:
>>   But this thread is from Facebook trying to change that. To side step 
>> imports.
> No they're not. It's a couple sections in a blog post that is being wildly 
> misinterpreted.

Today's blog posts are the press releases of past years. It would have
been quite possible to run it past the responsible organs of the
organisation they were writing about, as it would have been customary in
earlier days.

Simon

>
> * Mikel Maron * +14152835207 @mikel s:mikelmaron
>
>
>
>
>
>
> On Friday, March 20, 2020, 02:18:54 PM EDT, Rory McCann 
>  wrote: 
>
>
>
>
>
> On 19/03/2020 20:15, Mikel Maron wrote:
>
>> This whole thread is blown out of proportion, and rehashing old 
>> theoretical debates about imports that are more or less resolved in 
>> practice.
>
> Yes, we have an import guideline. But this thread is from Facebook 
> trying to change that. To side step imports.
>
> BTW the Etiqutte guidelines require you to assume all people here are 
> operating in good faith 
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



signature.asc
Description: OpenPGP digital signature
___
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

[Mikel Maron]

>  But this thread is from Facebook trying to change that. To side step imports.

No they're not. It's a couple sections in a blog post that is being wildly 
misinterpreted.

* Mikel Maron * +14152835207 @mikel s:mikelmaron






On Friday, March 20, 2020, 02:18:54 PM EDT, Rory McCann  
wrote: 





On 19/03/2020 20:15, Mikel Maron wrote:

> This whole thread is blown out of proportion, and rehashing old 
> theoretical debates about imports that are more or less resolved in 
> practice.


Yes, we have an import guideline. But this thread is from Facebook 
trying to change that. To side step imports.

BTW the Etiqutte guidelines require you to assume all people here are 
operating in good faith 


___
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

[Rory McCann]

On 19/03/2020 20:15, Mikel Maron wrote:
This whole thread is blown out of proportion, and rehashing old 
theoretical debates about imports that are more or less resolved in 
practice.


Yes, we have an import guideline. But this thread is from Facebook 
trying to change that. To side step imports.


BTW the Etiqutte guidelines require you to assume all people here are 
operating in good faith 


___
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

[Rory McCann]

On 19/03/2020 17:28, Christoph Hormann wrote:

I think I have said that in the past already:  "Assume good faith" as a
general principle can on OSM only work w.r.t. individuals taking full
and permanant responsibility for their own actions.  There cannot be an
assumption of good faith for inherently amoral corporate entities or
individuals making decisions on behalf of such entities.


Yep.

In addition, an assumption of good faith is a starting point that can be 
disproven by later conduct; it is not a perpetual mandate to be upheld 
even in the face of contrary evidence.


Facebook has been around for 15+ years. The same people are running it. 
We can look at their behaviour, at what they do, and predict what 
they're likely to do in the future.


___
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

[Jmapb]

On 3/19/2020 3:17 PM, Mikel Maron wrote:

> How would a mapper performing imports via RapiD comply with the
import guidelines?

By complying with the guidelines before setting up an import process
that leveraged RapiD for conflation.


That doesn't sound so bad to me, pending further details.

But it's not the first thing that leaps to mind when reading the blog
post, which claims that RapiD will allow imports by normal users who
find the traditional import process "too onerous." Current RapiD
workflow (in my experience) is "AI thinks a road/building is here and
looks like this. If you agree, click to add it." Changing the source
from AI-enhanced satellite imagery to "authoritative dataset" and I
picture a similar process: "Data Authority X thinks Y is here. If you
agree, click to add it." You can see how this sounds like an end-run
around the import guidelines, because it's performing an import without
a dedicated import account.

A good conflation tool would process a prospective dataset pre-import,
comparing OSM data against one or more external data sources and
assisting with other forms of data cleanup. If RapiD had a mode like
this, which allowed crowdsourced conflation instead of live map editing,
that could be useful.  The resulting (hopefully improved) dataset could
then be considered as a candidate for an import according to the
standard import guidelines. But offhand I imagine casual users would be
confused if the same piece of software is sometimes a live map editor,
and sometimes a pre-import conflation tool.

Jason

___
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

[Hartmut Holzgraefe]

On 19.03.20 20:02, Mateusz Konieczny via talk wrote:

> But (at least to me) "dissemination of authoritative data sets" sounds like
> "overwriting OSM data with external dataset" or "importing just because
> it is official".
> 
> Just yesterday I was explaining to one of mappers that it is OK to map
> roads
> that are not existing according to the official data.

we had sort of precedence with the official ALKIS land register data and
the JOSM Tracer2 plugin in the state of Northrhine-Westphalia in
Germany, where we were allowed to use the official land register layer
to trace building outlines. (Permission to use that data was removed a
while ago, but has just recently been restored again)

Tracer2 wasn't really anything that I would call an AI, but it most of
the times did a good job in copying building outlines from the ALKIS
layer by doing simple image tracing.

You just had to click inside the building outline in the ALKIS layer,
and Tracer2 would add the building outline to the OSM data layer.

So this was sort of an automated import with human filter on an
object by object basis, too.

But we also learned from that:

* do not blindly trust the official data

* compare it to a second source, to the most recent aerial pictures
  at least, but on the ground always wins

With the current topic at hand, aerial images would not really be
a true 2nd source, as the AI would also extract its suggestions
from these to begin with ...

___
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

[Oleksiy Muzalyev]

The fundamental point of this discussion is that the AI, the Artificial 
Intelligence, does not exist yet. It is kind of a marketing gimmick.


Sure, there are good computer programs, there are sophisticated 
automatons, but there is no AI, except in movies and serials.


Let me give you an example. There are machines in restaurants, which 
wash the dishes. But the dishes must be cleaned manually from the food 
leftovers, before putting them into the dish-washing machine. The army 
of humans worldwide, millions of workers do this hard debilitating work 
every day and night, because there is no AI good enough to pick up the 
dish and clean it without breaking it.


Certainly, this problem could be solved by standardizing the dishes, 
making them suitable for the automation, but my point is that there is 
no AI smart enough to to do such a simple task, which even a child could 
do easily. And we want to give the "AI" of this sort the task of drawing 
the map of this complicated world.


Best regards,
Oleksiy

On 3/19/20 12:28, Frederik Ramm wrote:

Hi,

a propos a recent statement from our friends at Facebook in which they
make plans for the future of our project,

https://tech.fb.com/map-with-ai-updates/


Beyond AI-based data sets, one of the biggest challenges for OSM is importing 
even readily available authoritative data sets
...
our hope is that RapiD can become a tool that’s simple enough for anyone to 
import and verify new data sets and to make use of these powerful tools

I would like to reiterate that the "challenge" is not that it is
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.

I think that someone who cannot respect these basic tenets of
OpenStreetMap - that mappers on the ground have the last word on what
gets into OSM and what not - shouldn't be allowed to publish software
that interacts with our database. I think we should disallow any
contributions made with RapID/map-with-ai and friends.

Bye
Frederik




___
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

[Mikel Maron]

> What's your guess, who will care more for the map, people who have copied AI 
>generated data or those who have created it, or doesn't it matter and it's the 
>same?
Germany is awesome but not the only way things can develop. People who already 
care about OSM and have for years think rapid can help. They also recognize it 
has limitations. 
And btw, this thread started on the theoretical possibility of rapid being used 
for general purpose conflation, not AI proposed data.
Mikel

On Thursday, March 19, 2020, 11:12 AM, Martin Koppenhoefer 
 wrote:



Am Do., 19. März 2020 um 13:01 Uhr schrieb Mikel Maron :

Martin, have you actually tried RapiD? It doesnt resemble what you describe and 
does not disempower anyone.


it changes the way we add things, or at least has potential to significantly 
shift the relation of individual people creating geodata (bottom up) towards 
big players providing geodata (top down) which at best gets looked at and 
"confirmed" by the contributor who actually copies it in, at worst it is a 
click-through mechanical operation without any effective review.

 
 From talking to mappers in places with less developed maps than Germany, there 
is enthusiasm about a tool that will help their mapping processes, and a 
thorough understanding of the limits of the approach.


as always, you can find both, people applauding and people opposing. If Germany 
had started with a process like this, they would not be where they are now (a 
vital community of active mappers). To keep the data useful, permanent 
maintenance is required. What's your guess, who will care more for the map, 
people who have copied AI generated data or those who have created it, or 
doesn't it matter and it's the same?
CheersMartin
___
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

[Mikel Maron]

> How would a mapper performing imports via RapiD comply with the import 
>guidelines?
By complying with the guidelines before setting up an import process that 
leveraged RapiD for conflation.
Mikel

On Thursday, March 19, 2020, 11:28 AM, Jmapb  wrote:

 On 3/19/2020 7:57 AM, Mikel Maron wrote:
  
 
There is nothing here about circumventing our well defined import guidelines, 
or disrespecting our basic tenets. 
  
The blog post says "The process of creating an import is too onerous for many 
users" and "Our hope is that RapiD can become a tool that’s simple enough for 
anyone to import and verify new data sets."
 
 
How would a mapper performing imports via RapiD comply with the import 
guidelines?
 
Jason

  ___
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

[Mikel Maron]

Some imports are good, some are bad. We have ways to asses them with 
guidelines. There are tools to help the technical process. Maybe there’s more 
possibilities with rapid on tooling, maybe not. Seems pretty simple.
This whole thread is blown out of proportion, and rehashing old theoretical 
debates about imports that are more or less resolved in practice.

Mikel

On Thursday, March 19, 2020, 2:44 PM, Tobias Knerr  wrote:

On 19.03.20 17:54, Jóhannes Birgir Jensson wrote:
> So - why are authoritative data sets an unwelcome addition?

At its core, OSM is a platform for collaboratively editing geodata. So
the following would be strong reasons not to import a dataset:

- other mappers should not edit it (because the dataset is the official
source and changing it would just make it wrong)
- other mappers cannot meaningfully edit it (because we cannot see the
object in the real world and don't have access to useful sources).

The way you describe it, collaborative editing doesn't seem to be a net
benefit to your scenario, and in fact makes it harder to sync updates
with the authoritative source.

So as a thought experiment: Why not just convert your dataset to the OSM
format to make it compatible with the OSM ecosystem, but skip the import
into the main OSM database?

In practice, I guess part of the answer for that is discoverability: Who
wants to hunt down datasets scattered across various servers and
portals? So it's tempting to put it all into a single big database. And
I guess that's ok as long as it doesn't get in the way of the main
purpose of that database too much – which is collaborative editing, not
data distribution. But surely, with a decent implementation of
compatible data layers tracked in some central repository, authoritative
data could be used *with* OSM without being *in* OSM.

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

Re: [OSM-talk] OSM is not the place for dissemination of authoritative data sets

[Mateusz Konieczny via talk]

Mar 19, 2020, 12:57 by mikel.ma...@gmail.com:

> Frederik, you’re crying out against phantoms, and getting stuck on one 
> interpretation of the word “authoritative”, and using that misinterpretation 
> as an excuse to beat on one of your favorite punching bags, and try to exact 
> radical unrational restrictions on a piece of software.
>
> What Facebook is saying here is that RapiD can make the technical part of the 
> import process easier. It’s a well done conflation process that has every 
> single new feature individually examined by a mapper.
>
> There is nothing here about circumventing our well defined import guidelines, 
> or disrespecting our basic tenets. It’s just your imagination.
>
Sorry but no. They are clearly trying to get around how import process 
currently works.
It is not just conflation tool. Can you link me to the OSM Wiki page 
documenting Facebook 
import of automatically detected buildings?

>From what I remember they circumvented our well defined import guidelines.

First by making edits without going through a proposal process (importing walls 
in Egypt
as roads etc).

Later by making editor and asking other to make edits on their behalf (what 
could be acceptable
if this people are actually reviewing data, not clicking "add all" without 
proper checks).

___
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

[Mateusz Konieczny via talk]

Mar 19, 2020, 12:28 by frede...@remote.org:

> Hi,
>
> a propos a recent statement from our friends at Facebook in which they
> make plans for the future of our project,
>
> https://tech.fb.com/map-with-ai-updates/
>
>> Beyond AI-based data sets, one of the biggest challenges for OSM is 
>> importing even readily available authoritative data sets
>> ...
>> our hope is that RapiD can become a tool that’s simple enough for anyone to 
>> import and verify new data sets and to make use of these powerful tools
>>
I agree that it sounds like "we are building tool that will let us ignore
import guidelines"

> I would like to reiterate that the "challenge" is not that it is
> difficult to import "authoritative data sets"; the problem is that
> authoritative data sets are fundamentally incompatible with the way we
> operate in OpenStreetMap.
>
I would not say so strongly, some datasets can be imported and were very useful
(for example address data in Poland - where are imported settlement
by settlement, with significant effort to review and to not import low
quality areas ).

>  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.
>
Yes, not everything is importable.

> I think that someone who cannot respect these basic tenets of
> OpenStreetMap - that mappers on the ground have the last word on what
> gets into OSM and what not - shouldn't be allowed to publish software
> that interacts with our database. I think we should disallow any
> contributions made with RapID/map-with-ai and friends.
>
Is there any case of actually misusing RapiD to make imports
in violation of import guidelines?

Is there case where RapiD developers refused to modify/fix
features that encourage mindless importing without review?

I dislike FB (and their ongoing refusal to properly attribute OSM
on maps that they are displaying is not improving my opinion),
but I would not ban them based on just that.

___
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

[Mateusz Konieczny via talk]

Mar 19, 2020, 17:54 by j...@betra.is:

> 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.
>
In some cases importing official datasets is helpful.

But (at least to me) "dissemination of authoritative data sets" sounds like
"overwriting OSM data with external dataset" or "importing just because it is 
official".

Just yesterday I was explaining to one of mappers that it is OK to map roads 
that are not existing according to the official data.

___
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

[Tobias Knerr]

On 19.03.20 17:54, Jóhannes Birgir Jensson wrote:
> So - why are authoritative data sets an unwelcome addition?

At its core, OSM is a platform for collaboratively editing geodata. So
the following would be strong reasons not to import a dataset:

- other mappers should not edit it (because the dataset is the official
source and changing it would just make it wrong)
- other mappers cannot meaningfully edit it (because we cannot see the
object in the real world and don't have access to useful sources).

The way you describe it, collaborative editing doesn't seem to be a net
benefit to your scenario, and in fact makes it harder to sync updates
with the authoritative source.

So as a thought experiment: Why not just convert your dataset to the OSM
format to make it compatible with the OSM ecosystem, but skip the import
into the main OSM database?

In practice, I guess part of the answer for that is discoverability: Who
wants to hunt down datasets scattered across various servers and
portals? So it's tempting to put it all into a single big database. And
I guess that's ok as long as it doesn't get in the way of the main
purpose of that database too much – which is collaborative editing, not
data distribution. But surely, with a decent implementation of
compatible data layers tracked in some central repository, authoritative
data could be used *with* OSM without being *in* OSM.

Tobias

___
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] [OSM-dev] OpenStreetMap Carto release v5.0.0

[Paul Norman via talk]

On 2020-03-19 1:18 a.m., Hartmut Holzgraefe wrote:

On 19.03.20 02:07, Joseph Eisenberg wrote:

All style users who upgrade to v5.0.0 should re-import the rendering
database so that the changes to lua transformations will take effect.

As I'm running a "render as many styles as possible" installation based
on a "hstore all, hstore only, vith views on top to provide actual
expected schema" on print.get-map.org, what influence would this have
on the older styles?

"An update to Lua tag transforms, setting line vs polygon decisions
for new tags"

Is this really just about "What should end up in which table,
planet_osm_line vs. planet_osm_polygon?

In that case it would probably not matter at all ...?


There are a few things we fixed that will result in bugs if you render 
osm-carto 5.0.0 against a 4.x database, principally with z_order. I 
don't know if the reverse is true.


As time goes on and we render different features running 5.x against a 
4.x database will result in missing features.



___
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

[Jóhannes Birgir Jensson]

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

Re: [OSM-talk] OSM is not the place for dissemination of authoritative data sets

[Christoph Hormann]

On Thursday 19 March 2020, Mikel Maron wrote:
> Frederik, you’re crying out against phantoms, and getting stuck on
> one interpretation of the word “authoritative”, and using that
> misinterpretation as an excuse to beat on one of your favorite
> punching bags, and try to exact radical unrational restrictions on a
> piece of software. What Facebook is saying here is that RapiD can
> make the technical part of the import process easier. It’s a well
> done conflation process that has every single new feature
> individually examined by a mapper. There is nothing here about
> circumventing our well defined import guidelines, or disrespecting
> our basic tenets. It’s just your imagination.

I am not quite sure if you actually believe that or if this is a cold 
blooded (though obviously rather crude) attempt to gaslight Frederik.

-- 
Christoph Hormann
http://www.imagico.de/

___
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

[Christoph Hormann]

On Thursday 19 March 2020, Frederik Ramm wrote:
>
> I think that someone who cannot respect these basic tenets of
> OpenStreetMap - that mappers on the ground have the last word on what
> gets into OSM and what not - shouldn't be allowed to publish software
> that interacts with our database. I think we should disallow any
> contributions made with RapID/map-with-ai and friends.
>
> [...]

While i agree on the conclusion (although i would phrase it in a 
different way:  Such tools should be banned unless their 
operators/developers can demonstrate that they are predominantly used 
in compliance with the values of OSM) i find the idea that a coporation 
like Facebook would voluntarily respect the basic tenets of 
OpenStreetMap naive.  Why should they?  A company like Facebook will 
only value OSM in so far as it seems to promise to be profitable for 
them.

I think I have said that in the past already:  "Assume good faith" as a 
general principle can on OSM only work w.r.t. individuals taking full 
and permanant responsibility for their own actions.  There cannot be an 
assumption of good faith for inherently amoral corporate entities or 
individuals making decisions on behalf of such entities.

Don't be so naive to think that a company like Facebook would be guided 
by anything else than by what they think is profitable for them.  As 
everyone can see they don't even comply with the OSM license if they 
think (a) that it is of economic advantage for them and (b) that they 
can get away with it.

Regarding the matter itself here - i have written about this at length 
already more than two years ago:

http://blog.imagico.de/on-imitated-problem-solving/

W.r.t. the motivation of corporate data user to push these things into 
OSM (in short: "to change OSM from being a map by the people for the 
people into a project of crowd sourced slave work for the corporate AI 
overlords") nothing has changed since then.

-- 
Christoph Hormann
http://www.imagico.de/

___
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

[Jmapb]

On 3/19/2020 7:57 AM, Mikel Maron wrote:

There is nothing here about circumventing our well defined import
guidelines, or disrespecting our basic tenets.


The blog post says "The process of creating an import is too onerous for
many users" and "Our hope is that RapiD can become a tool that’s simple
enough for anyone to import and verify new data sets."

How would a mapper performing imports via RapiD comply with the import
guidelines?

Jason

___
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

[Martin Koppenhoefer]

Am Do., 19. März 2020 um 13:01 Uhr schrieb Mikel Maron <
mikel.ma...@gmail.com>:

> Martin, have you actually tried RapiD? It doesnt resemble what you
> describe and does not disempower anyone.
>


it changes the way we add things, or at least has potential to
significantly shift the relation of individual people creating geodata
(bottom up) towards big players providing geodata (top down) which at best
gets looked at and "confirmed" by the contributor who actually copies it
in, at worst it is a click-through mechanical operation without any
effective review.



> From talking to mappers in places with less developed maps than Germany,
> there is enthusiasm about a tool that will help their mapping processes,
> and a thorough understanding of the limits of the approach.
>


as always, you can find both, people applauding and people opposing. If
Germany had started with a process like this, they would not be where they
are now (a vital community of active mappers). To keep the data useful,
permanent maintenance is required. What's your guess, who will care more
for the map, people who have copied AI generated data or those who have
created it, or doesn't it matter and it's the same?

Cheers
Martin
___
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

[Mikel Maron]

Martin, have you actually tried RapiD? It doesnt resemble what you describe and 
does not disempower anyone. From talking to mappers in places with less 
developed maps than Germany, there is enthusiasm about a tool that will help 
their mapping processes, and a thorough understanding of the limits of the 
approach.
Mikel

On Thursday, March 19, 2020, 7:51 AM, Martin Koppenhoefer 
 wrote:

Am Do., 19. März 2020 um 12:32 Uhr schrieb Frederik Ramm :

I think that someone who cannot respect these basic tenets of
OpenStreetMap - that mappers on the ground have the last word on what
gets into OSM and what not - shouldn't be allowed to publish software
that interacts with our database. I think we should disallow any
contributions made with RapID/map-with-ai and friends.


I support this notion. OSM should remain the project where local people add 
facts, not a collection of probable geo data as identified by AI (based just on 
remote sensing and without a clue of the "on the ground situation"). For many 
tasks it more important that the information is reliable (and maybe obviously 
incomplete) than apparently "complete". From am political point of view, OSM is 
a project that gave the power to the people and we have been working hard to 
make a success. Let's not hand the power over to big business now.
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] OSM is not the place for dissemination of authoritative data sets

[Mikel Maron]

Frederik, you’re crying out against phantoms, and getting stuck on one 
interpretation of the word “authoritative”, and using that misinterpretation as 
an excuse to beat on one of your favorite punching bags, and try to exact 
radical unrational restrictions on a piece of software.
What Facebook is saying here is that RapiD can make the technical part of the 
import process easier. It’s a well done conflation process that has every 
single new feature individually examined by a mapper.
There is nothing here about circumventing our well defined import guidelines, 
or disrespecting our basic tenets. It’s just your imagination.
There are totally rational ways to engage with an idea like using rapid for 
conflation. Let’s do that, and figure out how we can make OSM better with 
productive conversation.
Mikel

On Thursday, March 19, 2020, 7:28 AM, Frederik Ramm  wrote:

Hi,

a propos a recent statement from our friends at Facebook in which they
make plans for the future of our project,

https://tech.fb.com/map-with-ai-updates/

> Beyond AI-based data sets, one of the biggest challenges for OSM is importing 
> even readily available authoritative data sets
> ...
> our hope is that RapiD can become a tool that’s simple enough for anyone to 
> import and verify new data sets and to make use of these powerful tools

I would like to reiterate that the "challenge" is not that it is
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.

I think that someone who cannot respect these basic tenets of
OpenStreetMap - that mappers on the ground have the last word on what
gets into OSM and what not - shouldn't be allowed to publish software
that interacts with our database. I think we should disallow any
contributions made with RapID/map-with-ai and friends.

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] OSM is not the place for dissemination of authoritative data sets

[Martin Koppenhoefer]

Am Do., 19. März 2020 um 12:32 Uhr schrieb Frederik Ramm <
frede...@remote.org>:

> I think that someone who cannot respect these basic tenets of
> OpenStreetMap - that mappers on the ground have the last word on what
> gets into OSM and what not - shouldn't be allowed to publish software
> that interacts with our database. I think we should disallow any
> contributions made with RapID/map-with-ai and friends.



I support this notion. OSM should remain the project where local people add
facts, not a collection of probable geo data as identified by AI (based
just on remote sensing and without a clue of the "on the ground
situation"). For many tasks it more important that the information is
reliable (and maybe obviously incomplete) than apparently "complete". From
am political point of view, OSM is a project that gave the power to the
people and we have been working hard to make a success. Let's not hand the
power over to big business now.

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

[OSM-talk] OSM is not the place for dissemination of authoritative data sets

[Frederik Ramm]

Hi,

a propos a recent statement from our friends at Facebook in which they
make plans for the future of our project,

https://tech.fb.com/map-with-ai-updates/

> Beyond AI-based data sets, one of the biggest challenges for OSM is importing 
> even readily available authoritative data sets
> ...
> our hope is that RapiD can become a tool that’s simple enough for anyone to 
> import and verify new data sets and to make use of these powerful tools

I would like to reiterate that the "challenge" is not that it is
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.

I think that someone who cannot respect these basic tenets of
OpenStreetMap - that mappers on the ground have the last word on what
gets into OSM and what not - shouldn't be allowed to publish software
that interacts with our database. I think we should disallow any
contributions made with RapID/map-with-ai and friends.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk] [OSM-dev] OpenStreetMap Carto release v5.0.0

[Hartmut Holzgraefe]

On 19.03.20 02:07, Joseph Eisenberg wrote:
> All style users who upgrade to v5.0.0 should re-import the rendering
> database so that the changes to lua transformations will take effect.

As I'm running a "render as many styles as possible" installation based
on a "hstore all, hstore only, vith views on top to provide actual
expected schema" on print.get-map.org, what influence would this have
on the older styles?

"An update to Lua tag transforms, setting line vs polygon decisions
   for new tags"

Is this really just about "What should end up in which table,
planet_osm_line vs. planet_osm_polygon?

In that case it would probably not matter at all ...?

-- 
hartmut

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

Re: [OSM-talk] [OSM-dev] OpenStreetMap Carto release v5.0.0

[Joseph Eisenberg]

All style users who upgrade to v5.0.0 should re-import the rendering
database so that the changes to lua transformations will take effect.

Because of this requirement, it may take longer than usual for this
version to be implemented by the rendering servers for the "Standard"
map tile layer at openstreetmap.org

On 3/19/20, Paul Norman via dev  wrote:
> Dear all,
>
> Today, v5.0.0 of the OpenStreetMap Carto stylesheet (the default
> stylesheet on the OSM website) has been released. Once changes are deployed
> on the openstreetmap.org it will take couple of days before all tiles
> show the new rendering.
>
> Changes include
> - An update to Lua tag transforms, setting line vs polygon decisions
>    for new tags
>
> - Added upper way_area limits to most features using ST_PointOnSurface
>    to avoid performance problems from large polygons
>
> - Moved MSS files into their own directory
>
> - Removed rendering of power=cable features
>
> - Removed overlay pattern for natural=sand
>
> - Reduced landcover fading at mid-low zoom levels
>
> - Removed rendering of barrier=kerb
>
> Thanks to all the contributors for this release.
>
> For a full list of commits, see
> https://github.com/gravitystorm/openstreetmap-carto/compare/v4.25.0...v5.0.0
>
> As always, we welcome any bug reports at
> https://github.com/gravitystorm/openstreetmap-carto/issues
>
>
> ___
> dev mailing list
> d...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>

___
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

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

[Rory McCann]

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] OSM user diary etiquette

[Alex Kemp]

This is my first post within these mailman lists. Just in case I make 
some mistake that leads to this message not getting placed in the lists 
correctly, the post that I am trying to respond to is at:–

https://lists.openstreetmap.org/pipermail/talk/2019-June/082747.html

1. https://www.stopforumspam.com/forum/viewtopic.php?pid=50236#p50236 :
• (email) Re: [Ticket#201906221073] Alex: Enough with the Insults 
and Comdemnation (sic)
• 24/06/2019, 23:00: “we have removed your latest diary entry because it 
was considered too offensive”


The discussion in the post linked at top is very one-sided. None of the 
“obnoxious behaviour” can be viewed, since the posts mentioned have been 
removed. Well, joy! Although 12 posts total were deleted by the DWG, 
11 were saved by myself at the time and many of them can be viewed 
elsewhere so that unbiased persons can make up their own mind as to just 
how vile these posts were (not). So, in reverse order:–


(You will be disappointed if you are hoping to read lots of insults 
and/or swearing)


2. https://www.stopforumspam.com/forum/viewtopic.php?pid=50239#p50239 :
• A Stranger at your Table 2019-06-24
• (the word-for-word post mentioned in [1] above that sparked removal of 
all Spam-info posts in OSM Diaries)


3. https://github.com/openstreetmap/operations/issues/308 :
• Github email 2019-06-22: “A maintainer of the @openstreetmap 
organization has blocked you”


4. https://www.openstreetmap.org/user/alexkemp/diary/390252 :
• Post about AST Auto Centre + spam in OSM 2019-06-05, re-posted 
2019-08-06 (spam-related material removed for clarity): “PoI Musings”


5. https://www.stopforumspam.com/forum/viewtopic.php?pid=50184#p50184 :
• Post about spam in OSM 2019-05-18: “OSM is now within an iteration of 
spam-bot software (such as XRumer)”


6. https://www.openstreetmap.org/user/alexkemp/diary/390418 :
• Post about spam in OSM 2019-05-12, re-posted 2019-07-12: “How to Stop 
the Spam-Storm”


7. https://www.stopforumspam.com/forum/viewtopic.php?pid=50245#p50245 :
8. https://www.openstreetmap.org/user/alexkemp/diary/390250 :
• Post about spam in OSM 2019-05-06, re-posted 2019-07-12: “Recent Spam 
Attacks”
• (a set of statistics, originated to discover whether the then-recent 
spam attacks were human or bot-attacks)


9. https://www.openstreetmap.org/user/alexkemp/diary/158832 :
• Post about spam in OSM 2019-05-03: “Behold Cassandra”
• (this is the single post about spam in OSM that was NOT removed. Yet.)

10. https://www.stopforumspam.com/forum/viewtopic.php?pid=50404#p50404 :
• Email to TomH + Firefishy 2019-09-16: opportunity to use/test a 
k-anonymity SFS API (zero response)


In Summary:–

OSM == OpenStreetMap
DWG == Data Working Group

https://www.openstreetmap.org/diary
https://www.openstreetmap.org/user/alexkemp/diary

https://en.wikipedia.org/wiki/Narcissism
https://en.wikipedia.org/wiki/Cabal
https://en.wikipedia.org/wiki/Rat_king
https://en.wikipedia.org/wiki/Going_postal

A bunch of OSM folks, joined at the tail by the common mental 
disturbance known as Narcissism, got butt-hurt by (in part) the fact of 
my pointing out that they were malignant narcissists, and went postal on 
me. Unfortunately for myself, they
Ⅰ. had controls of levers that allowed them to remove Diary posts that, 
in some cases, had taken me more than 11 hours to research & write, and
Ⅱ. were malignant narcissists, which meant that they would do everything 
in their power to harm me.


If you stand to one side and kind of squint at all of this, and after 
reading all the available posts (above), and especially after reading 
the extract from the email sent to me by one of the executives of the 
DWG (bottom), you now need to re-join your bottom jaw to your top-jaw. 
And yes, this really is Real Life. And it is about to get worse, since 
it appears that some of these folks may be engaging in financial 
mismanagement (at best) and/or corruption (at worst)…


A. https://www.openstreetmap.org/user/Nakaner/diary/42916 :
• Post about 2017 OSMF Board Elections 2017-12-08: “analysis of the 
candidates”
• Heather Leson: “rarely active mapper … member of the HOT US Inc. … 
would like to introduce a strong code of conduct with an enforcement … 
emphasized her fundraising skills on the HOT board but did not collect 
any money” … et al
• Emails from Nicolas Chavent (co-founder of HOT) + Severin Menard 
(long-time member of HOT) reveal effects of a code of conduct complaint 
within HOT, plus it running out of money whilst Leson was in charge


B. https://www.openstreetmap.org/user/SeverinGeo/diary/42854 :
• Post in OSM Diary 2017-12-01: “Leaving the HOT US Corporation”
• Severin Menard: “secrecy and lies were core within the board toward 
the membership … End of September 2015, HOT US Inc should still have 
approximately USD $152,000 for activities still to be done or to be 
returned for one large multiple years project, while the bank account 
was around only USD $10K.”


C. 

Re: [OSM-talk] [OSM-dev] tagtransform for OSM - An effort to make tagging and using OSM data easier; bridging different worlds together

[Sören Reinecke via talk]

Hello,

I think I need to provide an overview of tagtransform for you to
understand what I want to achieve and to get the idea of bridging. An
update of the repository with better explanation will follow. Some
things changed and some users inspired me so I forgot to update the
README.md accordingly.

Tagtransform specification: (Need ideas to add to the specification,
read here the specification and here you get to know how to contribute)
- The specification enables the convertion from one format to another
by inventing a language that acts as a connection point. This is useful
for offline usage of the rules in the format the app developer can
better work with.
- Bridge between languages
  - e.g. JOSM xml <--> tagtransform specification <--> iD json
  - Data Item database <--> tagtransform specification <--> JOSM xml
- You can contribute to tagtransform
  - by improving the specification
  - by developing scripts that use the specification
  - by developing converters that convert tagtransform specification to
other formats like JSOM xml

Role of validators:
- Validators can take the data from Data Items to create validation
rules
- and can also inspire the Data Item OSM Community by providing them
with validation suggestions.

Role of editors:
- Editors can take the data from Data Items to automatically transform
deprecated tags and to discard discardable tags.
- For offline usage they can fetch data from Data Items and can
transform them to tagtransform specification.
- Recommend a specified POI tagging through presets or automatically
transforming wrong used tags like deprecated ones to new ones.

OSM Data Item Community: (important because tagtransform will use data
they create)
- They have the necessary infrastructure to host key/tag data and they
have already a bunch of these inclusive validation rules and usage
rules.
- They're mappers and understand how keys/tags are used and can
transfer that to meta sphere used by data customers, editors and
validators.
- Go to the Data Item Wikipage to get what it is all about and how to
contribute to Data Items.

Bots/Scripts: (Please do not work on unless we make the specification
production-ready)
- Can be used to query Data Item database for preprocessing data for
later use like offline usage or data analysation at larger scale
- through converting received data to tagtransform specification.
- You can contribute to tagtransform by developing scripts that make
use of the Data Item database of OSM Wiki by fetching them and
converting them to tagtransform specification.

I hope this helps

Cheers

Sören Reinecke alias ValorNaram

-Original Message-
From: Sören Reinecke via dev 
Reply-To: Sören Reinecke 
To: d...@openstreetmap.org
Subject: [OSM-dev] tagtransform for OSM - A effort make tagging and
using OSM data easier; bridging different worlds together
Date: Thu, 05 Dec 2019 15:50:04 +0100

Hey all,

I currently write a specification for tranforming tags in OpenStreetMap
to make life of data customers easier. Different tagging schemes have
emerged since the existence of OpenStreetMap, same are existing in
parallel and a newer one deprecated an old one. Data customers without
knowing the OSM community much get lost. This project aims to help
developers who want to take advantage of the OpenStreetMap great
database which is by the way a brilliant project. This project can also
help to make tagging in OSM more orthogonal and more hassle free.

I saw conflicting interests between OSM community, OSM developers like
the iD developers and data customers. A renderer might need data in
another way as the community contributes. The community might need
another tagging scheme than a renderer. I thought how we can resolve
this, how we can get all sites on "one table" and that is the idea I
had come up with:

A more readable version can be found here: 
https://github.com/ValorNaram/transformation-table-osmtags/blob/master/README.md
and the principles can be found at 
https://github.com/ValorNaram/transformation-table-osmtags/blob/master/principles.md



Example 1: They want to have the phone number of a POI. There are some
problems with this:

1. They need to know both contact:phone and phone to get them all.
2. They need to support them both.
3. They need to remove one in case both keys are mapped on one POI.
This really happens, see http://overpass-turbo.eu/s/OI2.

Example 2: They want to know how many POI's have changing tables
(general: facilities for changing a nappy of a baby). There are some
problems with this too:

1. They need to know both changing_table and the deprecated diaper
to get them all.
2. They need to support them both. Difficult because they're highly
different tagging schemes.
3. They need to remove one in case both keys are mapped on one POI.
This really happens, see http://overpass-turbo.eu/s/OI5.

Example 3: They want to develop a mapping tool and want to correct
wrong typed in tags. There are some problems with 

Re: [OSM-talk] OSM very old data

[Tom Ka]

From my experience, all this weird things are caused by missing
history, so I would guess the export may be fine and current API
queries are incomplete thus showing incorrect information sometimes.

Bye

po 16. 12. 2019 v 12:33 odesílatel Martin Koppenhoefer
 napsal:
>
> Maybe the following is a result of the history not being available for older 
> times, in the v6-planet-060403.osm there are objects that seem they shouldn't 
> be there? E.g. node 393303 according to the current API has its first version 
> from Aug, 1 2007 (according to JOSM) or 31/07/2007 according to the website 
> (not sure which of them is showing UTC and which local time, neither are 
> telling it explicitly, or if it has to do which time is displayed: when the 
> changeset was created or closed).
> Anyway, this node shouldn't be in a dump from 2006 (supposing that the fact 
> there were redactions e.g. for the license change, would still be visible, 
> and that ids have not been reassigned even in these old days)?
>
> There are more nodes like this, e.g. 589954 
> https://www.openstreetmap.org/node/589954/history  (this one shows that 
> redactions are accounted for, because you can see that there is a version 1 
> and 2 which cannot be shown any more).
>
> 196651 https://www.openstreetmap.org/node/196651/history
> This last one indicates that something weird is going on with the API (maybe 
> due to missing history) because this is a deletion in version 1 and no 
> redactions are shown for this object.
>
> Cheers
> Martin

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

Re: [OSM-talk] OSM very old data

[Martin Koppenhoefer]

Maybe the following is a result of the history not being available for
older times, in the v6-planet-060403.osm there are objects that seem they
shouldn't be there? E.g. node 393303 according to the current API has its
first version from Aug, 1 2007 (according to JOSM) or 31/07/2007 according
to the website (not sure which of them is showing UTC and which local time,
neither are telling it explicitly, or if it has to do which time is
displayed: when the changeset was created or closed).
Anyway, this node shouldn't be in a dump from 2006 (supposing that the fact
there were redactions e.g. for the license change, would still be visible,
and that ids have not been reassigned even in these old days)?

There are more nodes like this, e.g. 589954
https://www.openstreetmap.org/node/589954/history  (this one shows that
redactions are accounted for, because you can see that there is a version 1
and 2 which cannot be shown any more).

196651 https://www.openstreetmap.org/node/196651/history
This last one indicates that something weird is going on with the API
(maybe due to missing history) because this is a deletion in version 1 and
no redactions are shown for this object.

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

Re: [OSM-talk] OSM very old data

[Tom Ka]

Just few final notes (mainly for list archive):

- oldest usable .osm file is from 2006-04-03. Those old files have
plenty of nodes and ways (segments), but very few tagged, so only
geometry is there.
(https://planet.openstreetmap.org/cc-by-sa/planet-060403-fromARobinson.osm.7z)
- The oldest object in CZ (one of my goals) with proof of history is
from 2005-08-15: https://www.openstreetmap.org/node/172533/history
(lowest id is 172510 from the same edit - can be seen in 2006-08-18
data, but it's not in .osc files)
- There is no complete history before 2006-04-03. There are change
files (.osc) per day starting from 2005-04-17 but without initial .osm
to start with, they are of limited use (but contain timestamp and some
user info, used to identify node 172533).
(https://planet.openstreetmap.org/cc-by-sa/history/2005/0417-0418.osc.gz)
- I tried to have a look on fosm.org (those old data are the same),
but seems they do not have old history either.

Thanks for all the support here.
tom.k

čt 12. 12. 2019 v 14:29 odesílatel Tom Ka  napsal:
>
> Hi,
>
> successfully processed all data from cc-by-sa folder up to 2006-04-03.
> All results in v0.6 are available here:
>
> https://osm.fit.vutbr.cz/extracts/
>
> Bye tom.k
>
> čt 5. 12. 2019 v 13:03 odesílatel Tom Ka  napsal:
> >
> > Just to note - most of these old (v0.3) data have errors in UTF-8
> > encoding in some tag values (mainly name).
> >
> > Bye tom.k
> >
> > so 30. 11. 2019 v 13:09 odesílatel Tom Ka  napsal:
> > >
> > > Final v0.6 extracts for planet are available here:
> > >
> > > http://osm.fit.vutbr.cz/extracts/
> > >
> > > Will prepare some info about the process for others.
> > >
> > > Thanks to all, who helped.
> > >
> > > pá 29. 11. 2019 v 11:05 odesílatel Frederik Ramm  
> > > napsal:
> > > >
> > > > Hi,
> > > >
> > > > On 29.11.19 10:43, Tom Ka wrote:
> > > > > What it
> > > > > the meaning - deleted segments, so should I ignore those ways?
> > > >
> > > > I guess so.
> > > >
> > > > > 2) from 061205 the size increases, so I guess it contain some
> > > > > reasonable data, but for older (planet-061128.osm.bz2 -
> > > > > planet-060818.osm.bz2  ) there is size jump, which is strange. Is
> > > > > there any reason for this?
> > > >
> > > > Possibly https://wiki.openstreetmap.org/wiki/Old_TIGER_Import_2005/2006
> > > >
> > > > 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] OSM very old data

[Tom Ka]

čt 12. 12. 2019 v 15:31 odesílatel Martin Koppenhoefer
 napsal:
>
> Very interesting! The timestamps are not valid (quite often there is a time 
> tag, which seems to be the GPG-logger time) and there is no user information 
> though. Also a lot of way ids are negative and all objects are in version 1. 
> Are these known limitations?
> I have only looked at v6-planet-060403.osm.bz2 so far

Timestamps have to be added where missing for following processing to
work (I use 2000-01-01 so you can see, what's artificial timestamp).
User info is missing in source v0.3 as well (but was not necessary for
processing to v0.6 so I did not add any dumb value). Version
information was not modified by me, and negative way ids are from the
04to05.pl script (segments to ways). Will publish the worksflow in a
diary soon, so anyone can check/repeat it.

Bye tom.k

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

Re: [OSM-talk] OSM very old data

[Martin Koppenhoefer]

Very interesting! The timestamps are not valid (quite often there is a time
tag, which seems to be the GPG-logger time) and there is no user
information though. Also a lot of way ids are negative and all objects are
in version 1. Are these known limitations?
I have only looked at v6-planet-060403.osm.bz2 so far

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

Re: [OSM-talk] OSM very old data

[Tom Ka]

Hi,

successfully processed all data from cc-by-sa folder up to 2006-04-03.
All results in v0.6 are available here:

https://osm.fit.vutbr.cz/extracts/

Bye tom.k

čt 5. 12. 2019 v 13:03 odesílatel Tom Ka  napsal:
>
> Just to note - most of these old (v0.3) data have errors in UTF-8
> encoding in some tag values (mainly name).
>
> Bye tom.k
>
> so 30. 11. 2019 v 13:09 odesílatel Tom Ka  napsal:
> >
> > Final v0.6 extracts for planet are available here:
> >
> > http://osm.fit.vutbr.cz/extracts/
> >
> > Will prepare some info about the process for others.
> >
> > Thanks to all, who helped.
> >
> > pá 29. 11. 2019 v 11:05 odesílatel Frederik Ramm  
> > napsal:
> > >
> > > Hi,
> > >
> > > On 29.11.19 10:43, Tom Ka wrote:
> > > > What it
> > > > the meaning - deleted segments, so should I ignore those ways?
> > >
> > > I guess so.
> > >
> > > > 2) from 061205 the size increases, so I guess it contain some
> > > > reasonable data, but for older (planet-061128.osm.bz2 -
> > > > planet-060818.osm.bz2  ) there is size jump, which is strange. Is
> > > > there any reason for this?
> > >
> > > Possibly https://wiki.openstreetmap.org/wiki/Old_TIGER_Import_2005/2006
> > >
> > > 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] OSM very old data

[Tom Ka]

Just to note - most of these old (v0.3) data have errors in UTF-8
encoding in some tag values (mainly name).

Bye tom.k

so 30. 11. 2019 v 13:09 odesílatel Tom Ka  napsal:
>
> Final v0.6 extracts for planet are available here:
>
> http://osm.fit.vutbr.cz/extracts/
>
> Will prepare some info about the process for others.
>
> Thanks to all, who helped.
>
> pá 29. 11. 2019 v 11:05 odesílatel Frederik Ramm  napsal:
> >
> > Hi,
> >
> > On 29.11.19 10:43, Tom Ka wrote:
> > > What it
> > > the meaning - deleted segments, so should I ignore those ways?
> >
> > I guess so.
> >
> > > 2) from 061205 the size increases, so I guess it contain some
> > > reasonable data, but for older (planet-061128.osm.bz2 -
> > > planet-060818.osm.bz2  ) there is size jump, which is strange. Is
> > > there any reason for this?
> >
> > Possibly https://wiki.openstreetmap.org/wiki/Old_TIGER_Import_2005/2006
> >
> > 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] OSM very old data

[Tom Ka]

Final v0.6 extracts for planet are available here:

http://osm.fit.vutbr.cz/extracts/

Will prepare some info about the process for others.

Thanks to all, who helped.

pá 29. 11. 2019 v 11:05 odesílatel Frederik Ramm  napsal:
>
> Hi,
>
> On 29.11.19 10:43, Tom Ka wrote:
> > What it
> > the meaning - deleted segments, so should I ignore those ways?
>
> I guess so.
>
> > 2) from 061205 the size increases, so I guess it contain some
> > reasonable data, but for older (planet-061128.osm.bz2 -
> > planet-060818.osm.bz2  ) there is size jump, which is strange. Is
> > there any reason for this?
>
> Possibly https://wiki.openstreetmap.org/wiki/Old_TIGER_Import_2005/2006
>
> 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] OSM very old data

[Frederik Ramm]

Hi,

On 29.11.19 10:43, Tom Ka wrote:
> What it
> the meaning - deleted segments, so should I ignore those ways?

I guess so.

> 2) from 061205 the size increases, so I guess it contain some
> reasonable data, but for older (planet-061128.osm.bz2 -
> planet-060818.osm.bz2  ) there is size jump, which is strange. Is
> there any reason for this?

Possibly https://wiki.openstreetmap.org/wiki/Old_TIGER_Import_2005/2006

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk] OSM very old data

[Maarten Deen]

On 2019-11-29 10:43, Tom Ka wrote:


https://kasparkovi.net/osm/
(top letf selection for older maps)


No answer to your questions, but cool to see the map grow like that!

Maarten

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

Re: [OSM-talk] OSM very old data

[Tom Ka]

Hi, I tried to convert the old 0.3 data and have some questions if
anybody remembers those days:
(all data are from https://planet.openstreetmap.org/cc-by-sa/ )

1) planet-061205.osm contains (other have similar too):











the 04to05.pl end with:




.

which is not valid for osmosis0-0.35 to further process it. What it
the meaning - deleted segments, so should I ignore those ways?

2) from 061205 the size increases, so I guess it contain some
reasonable data, but for older (planet-061128.osm.bz2 -
planet-060818.osm.bz2  ) there is size jump, which is strange. Is
there any reason for this?

I must admit, this OSM archeology is a sort of fun :-)

I already have tiles for old CZ maps up to 2007.10.10, have to prepare
some better UI, can have a look here:

https://kasparkovi.net/osm/
(top letf selection for older maps)

Bye tom.k

po 28. 10. 2019 v 10:07 odesílatel Tom Ka  napsal:
>
> Thank you, I was thinking about similar way too.
>
> Best tkk.
>
> so 26. 10. 2019 v 23:22 odesílatel Frederik Ramm  napsal:
> >
> > Hi,
> >
> > On 25.10.19 16:18, Tom Ka wrote:
> > > OK, one question that remains unanswered will be: what was the first
> > > object in Czech republic :-)
> >
> > Nodes are generally numbered in ascending order, and have been from the
> > start. Since anything that can be mapped either is a node or depends on
> > a node, it should be possible to find the node with the lowest node id
> > in the Czech Republic.
> >
> > I'll offer https://www.openstreetmap.org/node/172508 - the web site says
> > "Version #1 · Changeset #209315 - edited Tue 06 Feb 2007". At the same
> > time this node is already present in the file called
> > "planet-060501-FromLA2.osm.bz2" which purports to be from May 2006.
> > Subtract 8 from the node ID and you get a node where the API claims it
> > was first edited in August 2005, so something is a bit fishy here with
> > regards to the exact timestamps. Nonetheless, 172508 seems to be the
> > lowest node ID in the country. Incidentally it is still the lowest node
> > ID in the country today, but it is also the lowest node ID in that old
> > planet file.
> >
> > 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] OSM very old data

[Tom Ka]

Thank you, I was thinking about similar way too.

Best tkk.

so 26. 10. 2019 v 23:22 odesílatel Frederik Ramm  napsal:
>
> Hi,
>
> On 25.10.19 16:18, Tom Ka wrote:
> > OK, one question that remains unanswered will be: what was the first
> > object in Czech republic :-)
>
> Nodes are generally numbered in ascending order, and have been from the
> start. Since anything that can be mapped either is a node or depends on
> a node, it should be possible to find the node with the lowest node id
> in the Czech Republic.
>
> I'll offer https://www.openstreetmap.org/node/172508 - the web site says
> "Version #1 · Changeset #209315 - edited Tue 06 Feb 2007". At the same
> time this node is already present in the file called
> "planet-060501-FromLA2.osm.bz2" which purports to be from May 2006.
> Subtract 8 from the node ID and you get a node where the API claims it
> was first edited in August 2005, so something is a bit fishy here with
> regards to the exact timestamps. Nonetheless, 172508 seems to be the
> lowest node ID in the country. Incidentally it is still the lowest node
> ID in the country today, but it is also the lowest node ID in that old
> planet file.
>
> 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] OSM very old data

[Frederik Ramm]

Hi,

On 25.10.19 16:18, Tom Ka wrote:
> OK, one question that remains unanswered will be: what was the first
> object in Czech republic :-)

Nodes are generally numbered in ascending order, and have been from the
start. Since anything that can be mapped either is a node or depends on
a node, it should be possible to find the node with the lowest node id
in the Czech Republic.

I'll offer https://www.openstreetmap.org/node/172508 - the web site says
"Version #1 · Changeset #209315 - edited Tue 06 Feb 2007". At the same
time this node is already present in the file called
"planet-060501-FromLA2.osm.bz2" which purports to be from May 2006.
Subtract 8 from the node ID and you get a node where the API claims it
was first edited in August 2005, so something is a bit fishy here with
regards to the exact timestamps. Nonetheless, 172508 seems to be the
lowest node ID in the country. Incidentally it is still the lowest node
ID in the country today, but it is also the lowest node ID in that old
planet file.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk] OSM very old data

[Tom Ka]

pá 25. 10. 2019 v 15:08 odesílatel Frederik Ramm  napsal:
> On 25.10.19 09:52, Tom Ka wrote:
> > - any recommendation for tool/app/etc to process v0.3 data (up to
> > 01.05.2006 on planet/cc-by-sa) (and convert them to v0.6)?
>
> There's a perl script "04to05.pl" in SVN, this works for 0.3 data as well.

Perfect, will try. For archive, it can be found here:
https://svn.openstreetmap.org/applications/utils/conv05/

> > - is history before 01.05.2006 (easily) available (other archive or
> > local source) (Europe or CZ would be enough)?
>
> We didn't have history files at the time and those were times when we
> still used segments, so in today's history files these early times
> cannot be represented (at least not for ways). I am not aware of any
> older files. But the amount of .cz data in that old planet file is so
> small (7251 nodes and 7453 extremely short ways) that it probably
> wouldn't make a lot of sense to go back further.

OK, one question that remains unanswered will be: what was the first
object in Czech republic :-)

Thanks tkk.

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

Re: [OSM-talk] OSM very old data

[Frederik Ramm]

Hi,

On 25.10.19 09:52, Tom Ka wrote:
> - any recommendation for tool/app/etc to process v0.3 data (up to
> 01.05.2006 on planet/cc-by-sa) (and convert them to v0.6)?

There's a perl script "04to05.pl" in SVN, this works for 0.3 data as well.

> - is history before 01.05.2006 (easily) available (other archive or
> local source) (Europe or CZ would be enough)?

We didn't have history files at the time and those were times when we
still used segments, so in today's history files these early times
cannot be represented (at least not for ways). I am not aware of any
older files. But the amount of .cz data in that old planet file is so
small (7251 nodes and 7453 extremely short ways) that it probably
wouldn't make a lot of sense to go back further.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk] OSM very old data

[Tom Ka]

Most dumps/diffs are newer then 2007, the only older dirs are in
https://planet.osm.org/cc-by-sa/history/, but those are diffs (not
full dumps) and all in 2004 and lot in 2005 are empty, which is weird.
Being diffs I would need starting dump to update to use them anyway.

Bye tkk

pá 25. 10. 2019 v 13:48 odesílatel Mateusz Konieczny
 napsal:
>
>
>
>
> 25 Oct 2019, 09:52 by tomas.kaspa...@gmail.com:
>
> - is history before 01.05.2006 (easily) available (other archive or
> local source) (Europe or CZ would be enough)?
>
> https://planet.osm.org/cc-by-sa/ ?
>
> ___
> 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 very old data

[Mateusz Konieczny]

25 Oct 2019, 09:52 by tomas.kaspa...@gmail.com:

> - is history before 01.05.2006 (easily) available (other archive or
> local source) (Europe or CZ would be enough)?
>
https://planet.osm.org/cc-by-sa/  ?

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

[OSM-talk] OSM very old data

[Tom Ka]

Hello,

I'm trying to create map of Czech Republic with older versions of OSM
data. No problem to proceed to 21.04.2009 (first v0.6 data) and with
older (0.35 + --migrate) osmosis to 10.10.2007 (first v0.5 data). All
data are from https://planet.openstreetmap.org/cc-by-sa/. I got in
troubles when I want to go further in history:

- any recommendation for tool/app/etc to process v0.3 data (up to
01.05.2006 on planet/cc-by-sa) (and convert them to v0.6)?
- is history before 01.05.2006 (easily) available (other archive or
local source) (Europe or CZ would be enough)?

Thank you in advance
tkk.

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

[OSM-talk] OSM Consultant Needed

[Joe Savage]

Hi,

I am currently looking for an OSM Data Consultant to provide some
assistance for us to move to ultising OSM data in a number of key use
cases. A rough outline can be viewed at
https://docs.google.com/document/d/1RtWl5bP-77j2cblp91lkC5YqfwnRV61jYtIJip2FyWo/edit?usp=sharing.
We see the value in OSM data going forward and we are happy to do some
accreditation as part of this of course. If anybody can help us in utiising
OSM as we want to please get in touch!

Many thanks,

-- 
Joe Savage
CTO
[image: Commercial People]
 +44 (0) 20 8594 8220 <02085948220>
 j.sav...@commercialpeople.com
 www.commercialpeople.com | www.residentialpeople.com
Angel House, 1st Floor, 225 Marsh Wall, London, E14 9FW
 

Commercial People Ltd accepts no liability for the content of this email,
or for the consequences of any actions taken on the basis of the
information provided unless that information is subsequently confirmed in
writing. If you are not the intended recipient you are notified that
disclosing, copying, distributing or taking any action in reliance on the
contents of this information is strictly prohibited.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM user diary etiquette

[dcapillae]

It would hurt a Philosophy student to read that.

Socrates didn't write anything. Plato would write it.

Excuse me for this off-topic.



--
Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html

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

Re: [OSM-talk] [OSM-legal-talk] Proposal for a revision of JA:Available Data

[Mateusz Konieczny]

5 Jul 2019, 05:22 by yumean1...@gmail.com:

> The main point at issue is whether we are allowed to use official websites 
> that provide primary information or not.
> Some of us think that we can use data from official websites unless it is 
> prohibited by their term of service.
>
I am not a lawyer, please correct me if I am wrong:
- facts are not copyrightable and from copyright view it does not matter 
whatever
one copied information from opening hours sign or from website
- collections of facts may have copyright or copyright like restrictions, 
copying
phone book or all branches of $CORPORATION may be not OK
- copying collections of facts is not OK also when distributed among many people
(that is why Wikidata is problematic - copying database one fact at time is not 
removing
sui generis database rights)

> is also against using official websites. His opinion is that we would able to 
> map POIs without surveying on the ground at all
> if it was OK to use data from websites. 
> (example: > 
> https://lists.openstreetmap.org/pipermail/talk-ja/2019-June/010604.html 
> >  )
>
1) Some survey is necessary to check whatever data is trustworthy and up to date
2) Even if true it would not influence copyright status of such data
3) Imports (mapping POIs without surveying) is acceptable in case of good data 
on a suitable
license and following import guidelines and there are cases of succesfull and 
useful imports
doing this.

> What do you think about the issue?
>
I am sure that mapping opening hours, name etc from signs is OK.
I am sure that mapping opening hours, name etc from website of individual 
business is OK.
I am sure that "we would able to map POIs without surveying on the ground at 
all" does not
matter as far as copyright status of such data is concerned.

I am not sure is it OK to systematically copy such data from website that is 
basically a database.
I am not sure is it OK to systematically copy such data from website that is 
basically a database,
with individuals copying one fact at time.

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

Re: [OSM-talk] OSM user diary etiquette

[Mateusz Konieczny]

25 Jun 2019, 11:19 by frede...@remote.org:

> I think that many soft rules, like "you shouldn't use this to post a
> question", can also be developed and enforced by the community without a
> well defined process and without ever being written down. If someone
> posts a question and three others tell them that this was not a good
> idea, they will likely learn, and everyone else who reads the exchange
> will learn, too.
>
I think that using diary entries for questions can be very useful and 
appropriate.

For example https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/35437 

that was basically a question "is this a good progress toward improving map 
style, 
or is there something that should be done differently?"

It resulted in a very useful feedback, especially  
"Ok - will try to explain briefly on the problem of too strong colors. (...)" 
but also
other comments.

There only other place where I could reasonably publish this was a Github 
repository,
where it would reach different and smaller group of people - even with 
announcement
on mailing lists.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM user diary etiquette

[Simon Poole]

There is a very big difference between "lively debate", and hurling
insults at individuals. Being of a different opinion than our system
administrators and expressing that, if very long in the tooth and
annoying in its repetitiveness is quite OK, and like most I simply
switched to ignoring the individuals posts. Calling people names is off
limits and doesn't need any additional confirmation in a CoC or whatever.

Simon

Am 25.06.2019 um 10:45 schrieb Harry Wood:
> I definitely support moderation actions on the diaries (or indeed any
> channel) when somebody steps way out of line.
>
> > It is unfortunate because this means that quite a few useful comments
> > written by some of you - the main subject was ways of fighting diary
> > spam - were dropped too.
>
> Do you have the option of *editing* a diary entry to delete sections
> of it, or even delete the whole text?  e.g. leaving a message
> "---This section has been removed because it did not meet our
> community standards".
>
> Not saying you should have done so in this case. Just wondering if it
> is an option.
> This would leave the comments. Some of the comments might then lack
> context, but it might still be a better outcome if the discussion was
> useful.
> Weirdly it's also a stronger moderation slap-down. The perpetrator
> suffers the ignominy of this message publicly on display within their
> diary. I've seen this approach a website elsewhere.
> I guess one consideration is that when diaries are moderated away,
> they are actually "soft deleted" whereas *editing* a diary would lose
> the original text.
>
> Anyway...  on the broader principle. At the risk of bringing back the
> "code of conduct" discussion... If we set out somewhere a set of
> community standards in terms of "be nice to eachother", but also the
> types of topics we expect to appear as OpenStreetMap diaries, what
> would we set out?
>
> I think we might decide that the standards of behaviour on the diaries
> should be higher than those of the mailing list. I mean the
> counterargument on the mailing list is always the desire to promote a
> "space for lively debate", but diaries are less of a discussion
> medium, more of a broadcast medium. We don't want to disallow people
> putting forth "political" thoughts or manifestos about the project,
> which inevitably will stray into bad-mouthing groups or even
> individuals on occasions, but in general we want diaries to be more
> carefully worded and well thought out. On balance a diary entry should
> be "respectful", "considerate", and "collaborative" ...but I'm quoting
> from the code of conduct now :-)
>
> We could also say diary entries should "make sense", e.g. minimum
> length. Not just some a few random words. This would allow us to
> delete quite a few weird diary entries from new users which clutter
> things (And they're possibly spammers flagging), but I'd be creating
> more work for moderations with that idea.
>
> We could also say diary entries should not be used a place to pose a
> question, or engage in communication styles which obviously fit better
> on other channels. For example I saw someone post a diary entry asking
> if the tile servers were currently offline. He argued that this was
> the best way to get attention, which may well be true, but it was an
> obvious misuse of the diaries feature to my mind.
>
> Harry
>
>
>
> On Tuesday, 25 June 2019, 00:23:34 BST, Frederik Ramm
>  wrote:
>
>
> Hi,
>
> I am writing this with my DWG hat on.
>
> The OSM user diaries are not routinely moderated but the DWG has the
> technical means to hide comments or whole posts, and will make use of
> these in extreme situations.
>
> I am writing to inform you that there as been one such situation, where
> a contributor time and time again over recent months used various
> expletives and insults to belittle the work of others in the project.
> He's been told to stop it numerous times; at one point when told that
> insults don't get him anywhere he said that he disagreed, because he had
> actually got a reaction to an insult. In another situation where he was
> told that his message could be heard better if he weren't wrapping it in
> so much bile, he responded "don't tell me what to do".
>
> We first tried to only hide those comments that were absolutely
> inacceptable ("viciuos brat", "violent little shit" etc.) but even those
> messages that were factual were always seasoned with a sentence
> explaining how this and that other person was an idiot, amateur, etc.,
> so in the end we just hid a handful of blog entries altogether. We
> wouldn't normally moderate someone for calling someone else an "amateur"
> but if it's framed by constant, stronger abuse then that lowers the bar
> considerably.
>
> It is unfortunate because this means that quite a few useful comments
> written by some of you - the main subject was ways of fighting diary
> spam - were dropped too.
>
> As I said, it's a rare exception for us to have to do this; these
> 

Re: [OSM-talk] OSM user diary etiquette

[Warin]

On 25/06/19 18:45, Harry Wood wrote:


Anyway...  on the broader principle. At the risk of bringing back the 
"code of conduct" discussion... If we set out somewhere a set of 
community standards in terms of "be nice to eachother", but also the 
types of topics we expect to appear as OpenStreetMap diaries, what 
would we set out?


I think we might decide that the standards of behaviour on the diaries 
should be higher than those of the mailing list. I mean the 
counterargument on the mailing list is always the desire to promote a 
"space for lively debate", but diaries are less of a discussion 
medium, more of a broadcast medium. We don't want to disallow people 
putting forth "political" thoughts or manifestos about the project, 
which inevitably will stray into bad-mouthing groups or even 
individuals on occasions,


Err ..no. The discussions should be about OSM, not about people or an 
individual.


I have found going through any outgoing mail, diary and eliminating the 
words 'you', 'they', even 'we' can lead to more objectivity on my part 
and hopefully less personal offence elsewhere.


There are a number of thing I don' like about OSM, trying to change them 
is one thing... abusing others with a different point of view? Not going 
to help.


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

Re: [OSM-talk] OSM user diary etiquette

[Frederik Ramm]

Hi,

On 25.06.19 10:45, Harry Wood wrote:
> Do you have the option of *editing* a diary entry to delete sections of
> it, or even delete the whole text? 

No. This is something the admins can do by fiddling directly with the
database, obviously, but there's no user interface for anyone but the
author doing it. I guess that would not be too difficult to change, but
that would then raise the question of whether we need to keep track of
changes (who made what change when), and thereby potentially open a
feature can of worms. Plus, since users can edit their own diary
entries, they could of course always remove the note saying that
something has been removed... you could argue this could become part of
a constructive process but I don't know, it sounds complicated.

> We could also say diary entries should "make sense", e.g. minimum
> length. Not just some a few random words. 

"Hello I am  and I am standing for election to  of " ;)

> We could also say diary entries should not be used a place to pose a
> question, or engage in communication styles which obviously fit better
> on other channels. For example I saw someone post a diary entry asking
> if the tile servers were currently offline. He argued that this was the
> best way to get attention, which may well be true, but it was an obvious
> misuse of the diaries feature to my mind.

Interestingly we have simply added the feature at some point, without
telling people what to use it for. The term "diary" - and I don't know
how it has been translated - seems to say that the idea was for people
to record what they have experienced (while mapping, I guess?), rather
than being a blog with general comments about the state of the world.
But then again, simply putting the feature out there and see what people
would use it for does have something very OSM-y to it.

I think that many soft rules, like "you shouldn't use this to post a
question", can also be developed and enforced by the community without a
well defined process and without ever being written down. If someone
posts a question and three others tell them that this was not a good
idea, they will likely learn, and everyone else who reads the exchange
will learn, too.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk] OSM user diary etiquette

[Harry Wood]

 I definitely support moderation actions on the diaries (or indeed any channel) 
when somebody steps way out of line.
> It is unfortunate because this means that quite a few useful comments> 
>written by some of you - the main subject was ways of fighting diary
> spam - were dropped too.
Do you have the option of *editing* a diary entry to delete sections of it, or 
even delete the whole text?  e.g. leaving a message"---This section has been 
removed because it did not meet our community standards".
Not saying you should have done so in this case. Just wondering if it is an 
option.
This would leave the comments. Some of the comments might then lack context, 
but it might still be a better outcome if the discussion was useful.Weirdly 
it's also a stronger moderation slap-down. The perpetrator suffers the ignominy 
of this message publicly on display within their diary. I've seen this approach 
a website elsewhere.I guess one consideration is that when diaries are 
moderated away, they are actually "soft deleted" whereas *editing* a diary 
would lose the original text.
Anyway...  on the broader principle. At the risk of bringing back the "code of 
conduct" discussion... If we set out somewhere a set of community standards in 
terms of "be nice to eachother", but also the types of topics we expect to 
appear as OpenStreetMap diaries, what would we set out?
I think we might decide that the standards of behaviour on the diaries should 
be higher than those of the mailing list. I mean the counterargument on the 
mailing list is always the desire to promote a "space for lively debate", but 
diaries are less of a discussion medium, more of a broadcast medium. We don't 
want to disallow people putting forth "political" thoughts or manifestos about 
the project, which inevitably will stray into bad-mouthing groups or even 
individuals on occasions, but in general we want diaries to be more carefully 
worded and well thought out. On balance a diary entry should be "respectful", 
"considerate", and "collaborative" ...but I'm quoting from the code of conduct 
now :-)
We could also say diary entries should "make sense", e.g. minimum length. Not 
just some a few random words. This would allow us to delete quite a few weird 
diary entries from new users which clutter things (And they're possibly 
spammers flagging), but I'd be creating more work for moderations with that 
idea.
We could also say diary entries should not be used a place to pose a question, 
or engage in communication styles which obviously fit better on other channels. 
For example I saw someone post a diary entry asking if the tile servers were 
currently offline. He argued that this was the best way to get attention, which 
may well be true, but it was an obvious misuse of the diaries feature to my 
mind.
Harry


On Tuesday, 25 June 2019, 00:23:34 BST, Frederik Ramm  
wrote:  
 
 Hi,

I am writing this with my DWG hat on.

The OSM user diaries are not routinely moderated but the DWG has the
technical means to hide comments or whole posts, and will make use of
these in extreme situations.

I am writing to inform you that there as been one such situation, where
a contributor time and time again over recent months used various
expletives and insults to belittle the work of others in the project.
He's been told to stop it numerous times; at one point when told that
insults don't get him anywhere he said that he disagreed, because he had
actually got a reaction to an insult. In another situation where he was
told that his message could be heard better if he weren't wrapping it in
so much bile, he responded "don't tell me what to do".

We first tried to only hide those comments that were absolutely
inacceptable ("viciuos brat", "violent little shit" etc.) but even those
messages that were factual were always seasoned with a sentence
explaining how this and that other person was an idiot, amateur, etc.,
so in the end we just hid a handful of blog entries altogether. We
wouldn't normally moderate someone for calling someone else an "amateur"
but if it's framed by constant, stronger abuse then that lowers the bar
considerably.

It is unfortunate because this means that quite a few useful comments
written by some of you - the main subject was ways of fighting diary
spam - were dropped too.

As I said, it's a rare exception for us to have to do this; these
messages, especially because they weren't one-off heat-of-the-moment
posts but a sustained onslaught, far surpassed in offensiveness anything
I've seen on this or any other OSM mailing list in recent years.

I won't say who the user is - those of you who were involved will
recognize it, and those who weren't probably shouldn't waste any time
with it.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk] OSM user diary etiquette

[Oleksiy Muzalyev]

Hi,

Socrates,  a Greek philosopher, wrote still more than two thousand years 
ago  "When the debate is lost, slander becomes the tool of the loser".


That is, soft words if presented in hard arguments can convey the 
message more efficiently. One more person had to learn this precious 
lesson the hard way.


Best regards,
Oleksiy

On 6/25/19 01:14, Frederik Ramm wrote:

Hi,

I am writing this with my DWG hat on.

The OSM user diaries are not routinely moderated but the DWG has the
technical means to hide comments or whole posts, and will make use of
these in extreme situations.

I am writing to inform you that there as been one such situation, where
a contributor time and time again over recent months used various
expletives and insults to belittle the work of others in the project.
He's been told to stop it numerous times; at one point when told that
insults don't get him anywhere he said that he disagreed, because he had
actually got a reaction to an insult. In another situation where he was
told that his message could be heard better if he weren't wrapping it in
so much bile, he responded "don't tell me what to do".

We first tried to only hide those comments that were absolutely
inacceptable ("viciuos brat", "violent little shit" etc.) but even those
messages that were factual were always seasoned with a sentence
explaining how this and that other person was an idiot, amateur, etc.,
so in the end we just hid a handful of blog entries altogether. We
wouldn't normally moderate someone for calling someone else an "amateur"
but if it's framed by constant, stronger abuse then that lowers the bar
considerably.

It is unfortunate because this means that quite a few useful comments
written by some of you - the main subject was ways of fighting diary
spam - were dropped too.

As I said, it's a rare exception for us to have to do this; these
messages, especially because they weren't one-off heat-of-the-moment
posts but a sustained onslaught, far surpassed in offensiveness anything
I've seen on this or any other OSM mailing list in recent years.

I won't say who the user is - those of you who were involved will
recognize it, and those who weren't probably shouldn't waste any time
with it.

Bye
Frederik




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

Re: [OSM-talk] OSM user diary etiquette

[Mateusz Konieczny]

25 Jun 2019, 01:14 by frede...@remote.org:

> As I said, it's a rare exception for us to have to do this; these
> messages, especially because they weren't one-off heat-of-the-moment
> posts but a sustained onslaught, far surpassed in offensiveness anything
> I've seen on this or any other OSM mailing list in recent years.
>
> I won't say who the user is - those of you who were involved will
> recognize it, and those who weren't probably shouldn't waste any time
> with it.
>
I just wanted to thank for taking action and using moderation tools in this 
situation.
It was unfortunately required.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OSM user diary etiquette

[Frederik Ramm]

Hi,

I am writing this with my DWG hat on.

The OSM user diaries are not routinely moderated but the DWG has the
technical means to hide comments or whole posts, and will make use of
these in extreme situations.

I am writing to inform you that there as been one such situation, where
a contributor time and time again over recent months used various
expletives and insults to belittle the work of others in the project.
He's been told to stop it numerous times; at one point when told that
insults don't get him anywhere he said that he disagreed, because he had
actually got a reaction to an insult. In another situation where he was
told that his message could be heard better if he weren't wrapping it in
so much bile, he responded "don't tell me what to do".

We first tried to only hide those comments that were absolutely
inacceptable ("viciuos brat", "violent little shit" etc.) but even those
messages that were factual were always seasoned with a sentence
explaining how this and that other person was an idiot, amateur, etc.,
so in the end we just hid a handful of blog entries altogether. We
wouldn't normally moderate someone for calling someone else an "amateur"
but if it's framed by constant, stronger abuse then that lowers the bar
considerably.

It is unfortunate because this means that quite a few useful comments
written by some of you - the main subject was ways of fighting diary
spam - were dropped too.

As I said, it's a rare exception for us to have to do this; these
messages, especially because they weren't one-off heat-of-the-moment
posts but a sustained onslaught, far surpassed in offensiveness anything
I've seen on this or any other OSM mailing list in recent years.

I won't say who the user is - those of you who were involved will
recognize it, and those who weren't probably shouldn't waste any time
with it.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

[OSM-talk] OSM and Urban planning

[john whelan]

In my mind I'd always thought about using OSM for urban planning to be
something for places with little money such as the third world but it
appears that in many places the economic boundaries of a city do not
coincide with the political boundaries and different levels of government
are involved in transport planning for example.

Locally in Ottawa we have two city councils, two provinces, federal
government and something called the NCC all involved in transportation
projects.

Rail lines and bus lines are justified by how many households are on the
line and how many businesses.

So how does this impact OpenStreetMap?

We are seeing a lot of buildings either being imported or mapped currently
across the world.  I'm not sure what the percentage of buildings and
building tags are but I suspect it is an increasing part of the database.

An apartment block has a lot of households so I can see an interest in
adding the number of apartments.

NGOs want to minimise the number of things such as clinics but at the same
time maximise the number of people who can access them.

Some groups are questioning city planners and using open source tools to
draw up alternative plans.  In Ottawa for example with at least six sources
of data it makes sense to use something like OSM to get everything in the
same format.

Commerical companies such as UrbanSim are using open data and use
OpenStreetMap in their presentations.  UrbanSim is a University spin off so
not quite a conventional commercial company and the same University does
provide a number of free open source programs to do planning on github.

Locally a mapper is interested in adding BIAs or Business Improvement Areas.

Land use by local city planners is divided into zones with local names such
as IP4 or TD3.

I'm not sure we should do anything at all but I think we should at least be
aware that OSM will start to see more urban planning related input and it
might be time to think about what the implications are.

Do we need some sort of standardised names in place of IP$ and BIA for
example?

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