Re: [Talk-it] Violazione licenza - Rally Alpi Orientali

[Aury88]

Però! 5^ segnalazione di violazione in meno di 3 settimaneannamo bene!




-
Ciao,
Aury
--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-ja] idによる変更が反映されない

[Satoshi IIDA]

こんにちは、はじめまして、いいだです。

iDエディタ上では更新されている、とのことなので、単純に時間がたてば反映されます。
ブラウザのキャッシュをクリアする必要があるかもしれませんが、
基本的にはページを更新すれば反映されます。

ただ、編集した対象によっては、標準レイヤへの適用に時間がかかる場合があります。（海岸線など）
この場合も基本的には時間がたてば自動的に反映が行われます。


2018年9月7日(金) 13:41 Kan Odagiri :

> 超初心者です。Idで既存の地図を編集したのですが、地図（standardのレイヤーに反映されません。）id
> の編集画面では変更されているのですが、どのようにすればよいのでしょうか？アドバイスを下さい。
>
>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[OSM-ja] idによる変更が反映されない

[Kan Odagiri]

超初心者です。Idで既存の地図を編集したのですが、地図（standardのレイヤーに反
映されません。）idの編集画面では変更されているのですが、どのようにすればよい
のでしょうか？アドバイスを下さい。



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

Re: [Talk-us] USPS Post Boxes

[Bryan Housel]

Can we please leave it as USPS?  Other shippers UPS, FedEx, and DHL are also 
abbreviated.
The “expand abbreviations” rule is really for street addresses, not everything 
in OSM.

Taginfo can show you what values are currently stored in the `operator` tag:
https://taginfo.openstreetmap.org/keys/operator#values 


If we were to switch the `operator` field in iD over to a taginfo-based 
autocomplete, 2 things would happen:
1. It would show exactly the results in the url above, which contains all the 
operators (not just the postal ones).  It would not be a good list to pick from.
2. The taginfo service would crash.  We’ve been asked by Jochen not to do 
lookups against tags with a lot of distinct values (like “name” and “operator”) 
because queries like this are resource intensive.

Thanks, Bryan




> On Sep 6, 2018, at 6:44 PM, Leif Rasmussen <354...@gmail.com> wrote:
> 
> Hi Peter,
> I would like to do the operator value conversion this weekend, but would also 
> like to make sure to listen to all the reasons for not expanding USPS.  These 
> include having the tagging style as consistent as possible, the long version 
> being harder to type, a list of semicolon separated expanded operators being 
> too long, and more.  These are valid concerns, which should be addressed 
> before anything else happens.  
> First, for keeping the tagging style as consistent as possible, each post box 
> will be given the tag "operator:wikidata"="Q668687".  This way, even if the 
> operator=* tags are changed later on, all post boxes will still be consistent 
> and easy to querry.
> Second, for making sure that the operator tag is not too hard to type, I 
> think that adding a taginfo based autocomplete to the operator=* field in iD 
> could solve this.  I would have to open an issue about that on Github, though.
> Third, another fear was that a list of expanded operators separated by 
> semicolons would be hard to work with.  I have no easy solution for this.  
> Perhaps, iD could have something to organize the operator tags into blocks, 
> rather than just text like other fields.
> I would like to convert the tags this weekend, so please let me know if you 
> have any suggestions for how to make the conversion less problematic.
> Thank you, 
> Leif Rasmussen
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

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

Re: [Talk-us] NYC Name Vandalism

[Alan Brown]

> In any case all of the above potentially lead to your private fork of the 
> planet getting out of sync real fast with the original, implying that 
> applying diffs will become 
> more problematic over time.  So you wouldn't be able to take you fixed and 
> known good planet fork, apply only good diffs, and expect to be able to 
> continue to do that > for a year or so.
No, that's not the idea at all.  It's to download planet files regular, 
identify problematic recent changes, revert only those.  You still need a 
history to revert.  Contribute back to the OSM community what the problematic 
attributes/object are, and a human can revert them.
 
> IMHO the only thing that could really work in the OSM model is reverting real 
> fast in the -original- dataset. 
Fixing the original dataset *is* paramount.  However, it's important to 
understand that there's this transitional problem; that, any given version of 
the dataset will have defects, and to catch the most egregious of these - 
particularly from vandalism is really the only goal here.  Not every use of OSM 
data will be pulled with high frequency from the database; there are offline 
applications where it's "pull once, use for a few years".  You may be able to 
rely on the community to repair persistent high-profile issues, but these 
transitory issues are another matter.
> Naturally there is the other aspect that we want our contributors to gain 
> experience and become better mappers over time. You are only going to get 
> that if leave the > opportunity to make mistakes open and don't robo-fix 
> everything that goes wrong 

It's not robo-fixing, it's "robo-flagging for moderation".  Fundamentally 
different thing.  Something that has be vetted could certainly violate any 
rules this flagging uses.

-Alan
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-ca] GitHub app for BC2020i Challenge

[OSM Volunteer stevea]

On Sep 6, 2018, at 4:30 PM, john whelan  wrote:
> The pilot project itself did manage to get a fair amount of accurate data 
> into OSM.  That data is still there and can be used.  It was instrumental in 
> supporting the HOT summit in Ottawa.  It managed to raise awareness within 
> local government both in Canada and in Africa about how OSM could be useful 
> and it clarified a number of legal issues about importing data.

Then, quite a number of events caused it to go off the rails.  OK, that 
happens; no judgement on my part, I'm far, far happier to try to watch the 
smoke clear and "might I offer to help?"

> > And I'm not boasting, but I did put some effort into the richest set of 
> > potential tags (harvested from our wikis) than I believe anybody else did, 
> > and I don't really have any specific interest in the project, except that 
> > it be a WELL RUN project.  (So I tried very hard to "seed it well"). 
> 
> You mean me getting the recumbent trike out and site inspecting a few hundred 
> buildings and adding tags to them was for nought?  How sad.

John, I'm on your side, the side of OSM having great data while it builds 
communities across Canada, universities, high schools, libraries, etc.  I'm 
happy the project has "stubbed in" (it's certainly "not nothing!") at least 
some data.  Dust off your hands and keep going!  (Is hopefully the attitude I'm 
encouraging you to adopt).

> There is still a gentle movement to gather more data over time, whether we 
> are keeping the current building data up to date is a separate issue.  Stats 
> is still trying to find ways to make building outlines available under their 
> Open Data license.

A 100% separate track for which I wish them the very best of luck.  That may or 
may not be successful, and CAN and SHOULD happen on a parallel track with OSM 
strategies which work.  I'll stand shoulder-to-shoulder with THAT spirit, as it 
is what makes OSM a very powerful OSM.

> The approach used on the pilot to import building outlines manually has been 
> picked up by Microsoft who have been making them available for the USA and I 
> understand Stats were involved with discussions with Microsoft about some 
> technical aspects.

Truly, I'm glad to hear it.  OSM and Microsoft (and now, it turns out, Stats 
Canada) do get symbiotic every once in a while, and we're all the better for it 
as/when it happens.

> The Ottawa pilot was a perfect storm in many ways with many different players 
> involved coming together.  Reproducing it is harder than it first seems.

I get that, so do others.  A "more valuable" aspect to pick up as a shiny coin 
from that is the learning experience that it is.  In QA this is called a "post 
mortem" and is one of the most valuable data chunks for "the next phase" (and 
there always is a next phase).

> What I would like to see is someone pick up doing analysis with R r.org to 
> see if we can build the feedback loops that might help motivate getting the 
> tags populated.

Heh, you could sketch up a wiki to get them started...! :-)  (It's not a bad 
idea, really).

Steve
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-de] EU-Urheberrechtsrichtlinie und ihre Folgen für OSM

[Volker]

Sind schon heftig groß die Kacheln. Hatte mir das etwas kleiner vorgestellt.

Aber ansonsten  volle Zustimmung 8-)


Am 06.09.2018 um 22:36 schrieb Michael Reichert:

Hallo,

Am 21.06.2018 um 01:16 schrieb Michael Reichert:

*Was können wir tun?*
Am Karlsruher Stammtisch hatten wir die Idee, als politisches Statement
einen Teil der Kartenkacheln von tile.openstreetmap.de in den nächsten
Tagen vorübergehend durch schwarze Kacheln mit einer politischen
Botschaft zu ersetzen. Es gibt schon grobe Pläne, wie wir das in der
Konfiguration des Tileservers umsetzen. Dennoch rufen wir zur Mithilfe
auf. Es ist nicht allein getan, die Konfiguration des Tileservers zu
ändern. Folgende weitere Dinge sind noch zu tun, bevor wir die schwarzen
Tiles ausliefern können:

1. Es muss eine Seite auf *.openstreetmap.de geben, die erklärt, was am
Entwurf der Richtlinie schlecht ist und warum die Filterpflicht uns
genau schadet. Auch ohne Webdesign-Kenntnisse könnt ihr hier mithelfen
und z.B. den Text formulieren oder Links zu weiteren Seiten zu diesem
Thema zusammenstellen.

2. Gut wäre es, wenn wir den Text auch ins Englische übersetzen könnten,
falls andere Tileserver-Betreiber und andere Local Chapter der OSMF es
uns gleichtun wollen.

3. Die schwarze Fehlerkachel, eine 256 x 256 Pixel große PNG-Datei muss
gestaltet werden. Vorschläge werden gerne entgegengenommen.

Vom 4. bis 11. September ist die Copyright Action Week gegen die
EU-Urheberrechtsrichtlinie.

https://de.saveyourinternet.eu/

Am 12. September stimmt das Plenum des Europäischen Parlaments erneut
über den Entwurf ab. Plattformen für die Entwicklung quelloffener
Software sind im Entwurf des Rechtsausschusses jetzt auch ausgenommen.

Die schwarzen Kacheln wurden heute Abend auf für dem deutschen
Tileserver, der vom FOSSGIS e.V. betrieben wird, aktiviert. Neun von
zehn (oder sind es acht von neun?) Anfragen nach einer Kartenkachel
werden wie üblich beantwortet. Die neunte/zehnte wird mit der schwarzen
Kachel beantwortet. Ein erzwungenes Neuladen (oft Strg+R), ggf.
verbunden mit dem Löschen des Caches, führt dazu, dass andere Kacheln
schwarz sind. Serverseitig wird pseudozufällig ausgewürfelt.

https://www.openstreetmap.de/karte.html

Die Startseite von openstreetmap.de hat einen niedrigen schwarzen Banner
am oberen Rand bekommen, der auf
https://www.openstreetmap.de/uf/index.html verlinkt. Dort gibt es
Informationen, warum manche Kacheln schwarz sind.


Wir werden unsere Serverkonfiguration Betreibern anderer kostenloser
Tileserver zur Verfügung stellen, damit diese sich ebenfalls für freie
Geodaten und gegen Uploadfilter aussprechen können.

Wer einen Tileserver betreibt und ebenfalls zufällige Tiles durch eine
Botschaft ersetzt ausliefern möchte, kann folgende Konfiguration
verwenden, wenn er Apache und mod_tile einsetzt:

Im VirtualHost vor den mod_tile-bezogenen Direktiven Folgendes einfügen
(getestet auf Ubuntu und Debian, andere Distributionen haben andere Pfade):

 RewriteEngine on
 RewriteMap gefiltert "rnd:/etc/apache2/gefiltert.txt"
 RewriteCond "${gefiltert:0}" "1"
 RewriteRule "^/(.*)(\d).png" "/savetheinternet.png" [PT]

/etc/apache2/gefiltert.txt hat folgenden Inhalt:

0 0|0|0|0|0|0|0|1

Ja, das Leerzeichen gehört so. Die Anzahl der Nullen bestimmt die
Wahrscheinlichkeit, ein normales Tile zu erhalten. gefiltert.txt muss in
/etc/apache2/ (Unterverzeichnis geht vermutlich auch) liegen.

savetheinternet.png sollte im DocumentRoot abgelegt werden. Ihr könnt
das PNG unter
https://wiki.openstreetmap.org/wiki/File:Savetheinternet.png
und das SVG unter
https://wiki.openstreetmap.org/wiki/File:Savetheinternet.svg
herunterladen.

herunterladen.

Viele Grüße

Michael





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


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

Re: [Talk-ca] GitHub app for BC2020i Challenge

[john whelan]

> Threads here, consensus and the wiki declared it dead, as it failed on a
number of fronts, primarily that it didn't respect OSM in certain ways in
which OSM must be respected.

The pilot project itself did manage to get a fair amount of accurate data
into OSM.  That data is still there and can be used.  It was instrumental
in supporting the HOT summit in Ottawa.  It managed to raise awareness
within local government both in Canada and in Africa about how OSM could be
useful and it clarified a number of legal issues about importing data.

> And I'm not boasting, but I did put some effort into the richest set of
potential tags (harvested from our wikis) than I believe anybody else did,
and I don't really have any specific interest in the project, except that
it be a WELL RUN project.  (So I tried very hard to "seed it well").

You mean me getting the recumbent trike out and site inspecting a few
hundred buildings and adding tags to them was for nought?  How sad.

There is still a gentle movement to gather more data over time, whether we
are keeping the current building data up to date is a separate issue.
Stats is still trying to find ways to make building outlines available
under their Open Data license. The feedback I'm referring to was the number
of buildings tagged and the total number of tags on the buildings.  When I
saw the analysis it was quite interesting to see the numbers going up.
What I didn't see is those parts of the map that had low numbers of
building tags.

The approach used on the pilot to import building outlines manually has
been picked up by Microsoft who have been making them available for the USA
and I understand Stats were involved with discussions with Microsoft about
some technical aspects.

The Ottawa pilot was a perfect storm in many ways with many different
players involved coming together.  Reproducing it is harder than it first
seems.

What I would like to see is someone pick up doing analysis with R r.org to
see if we can build the feedback loops that might help motivate getting the
tags populated.

Cheerio John

On 6 September 2018 at 16:39, OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> On Sep 6, 2018, at 1:14 PM, john whelan  wrote
> (replying to me, stevea):
> > > Hm, we tried to revive the wiki, a tried-and-true OSM methodology for
> doing EXACTLY that.  Is there something wrong with that idea?
> >
> > No this project was initiated by Stats Canada, but without clear
> requirements or feedback about what had been achieved.  The Stats Can side
> wasn't dependant on normal OSM mappers but my understanding was it was
> hoping to draw in new mappers.
>
> John, BC2020i (note the i) was initiated by Stats Canada.  Threads here,
> consensus and the wiki declared it dead, as it failed on a number of
> fronts, primarily that it didn't respect OSM in certain ways in which OSM
> must be respected.  It MIGHT have become resurrected as BC2020 (no i) and
> the wiki were attempts to do that, especially as Stats Canada was out of
> the picture by then, as they weren't going to contribute to either the wiki
> or the BC2020 itself, though, like anybody who "takes" (uses, and not in a
> bad way) OSM data, StatsCanada would be welcome to the results of BC2020
> (and BC2020i is dead, I'll say it one more time).  We stripped away what
> was wrong with "i" and slightly renamed the project to conform to the way
> that OSM has, can, does and will complete projects (including, but
> requiring that we use wikis).  BC2020 seems to have become moribund and
> ineffective, though I continue to hold out high hopes that it can be
> successful.
>
> OSM actually DOES have clear requirements or feedback, part of those are
> naturally "built in" to crowdsourced projects, part of those need a bit of
> goosing along by prompting volunteers to communicate well (wiki is ONE way,
> not the only way) via simple things like reporting progress and/or
> continuing to sharpen up focus because tagging started out as an early
> draft, but now is a "more complete" or "final" draft.  Sure, any good
> project wants to start out with clear goals (and should) but a modest bit
> of mid-course correction certainly won't prevent successful completion.
>
> > Fine but a couple of maperthons that were organised had data quality
> issues and no clear guidance about what tags were most valuable.
>
> That's because no QA was planned up front, just like I suggested to do
> last year and into January of this year.  And I'm not boasting, but I did
> put some effort into the richest set of potential tags (harvested from our
> wikis) than I believe anybody else did, and I don't really have any
> specific interest in the project, except that it be a WELL RUN project.
> (So I tried very hard to "seed it well").  In crowdsourcing, yes, this can
> be challenging, but communication is the lynchpin that allows it.  Wikis,
> at least in OSM can be and often are a critical component of the successful
> ongoing (status reporting, 

Re: [Talk-us] USPS Post Boxes

[Leif Rasmussen]

Hi Peter,
I would like to do the operator value conversion this weekend, but would
also like to make sure to listen to all the reasons for not expanding
USPS.  These include having the tagging style as consistent as possible,
the long version being harder to type, a list of semicolon separated
expanded operators being too long, and more.  These are valid concerns,
which should be addressed before anything else happens.
First, for keeping the tagging style as consistent as possible, each post
box will be given the tag "operator:wikidata"="Q668687".  This way, even if
the operator=* tags are changed later on, all post boxes will still be
consistent and easy to querry.
Second, for making sure that the operator tag is not too hard to type, I
think that adding a taginfo based autocomplete to the operator=* field in
iD could solve this.  I would have to open an issue about that on Github,
though.
Third, another fear was that a list of expanded operators separated by
semicolons would be hard to work with.  I have no easy solution for this.
Perhaps, iD could have something to organize the operator tags into blocks,
rather than just text like other fields.
I would like to convert the tags this weekend, so please let me know if you
have any suggestions for how to make the conversion less problematic.
Thank you,
Leif Rasmussen
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-GB] Wickham Market, Suffolk

[ajt1...@gmail.com]

Is anyone familiar with this area?  Someone's mentioned on IRC that 
Wickham Market has been changed from town to village and back a couple 
of times:


http://osm.mapki.com/history/node.php?id=114148812

Obviously it's been "town" more than village (and the person who added 
it as such was/is pretty local) - but is that still correct?  I'll 
comment on the latest change about this thread so that everyone's aware 
of it.


Best Regards,

Andy




___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-ca] GitHub app for BC2020i Challenge

[OSM Volunteer stevea]

On Sep 6, 2018, at 1:14 PM, john whelan  wrote (replying 
to me, stevea):
> > Hm, we tried to revive the wiki, a tried-and-true OSM methodology for doing 
> > EXACTLY that.  Is there something wrong with that idea? 
> 
> No this project was initiated by Stats Canada, but without clear requirements 
> or feedback about what had been achieved.  The Stats Can side wasn't 
> dependant on normal OSM mappers but my understanding was it was hoping to 
> draw in new mappers.

John, BC2020i (note the i) was initiated by Stats Canada.  Threads here, 
consensus and the wiki declared it dead, as it failed on a number of fronts, 
primarily that it didn't respect OSM in certain ways in which OSM must be 
respected.  It MIGHT have become resurrected as BC2020 (no i) and the wiki were 
attempts to do that, especially as Stats Canada was out of the picture by then, 
as they weren't going to contribute to either the wiki or the BC2020 itself, 
though, like anybody who "takes" (uses, and not in a bad way) OSM data, 
StatsCanada would be welcome to the results of BC2020 (and BC2020i is dead, 
I'll say it one more time).  We stripped away what was wrong with "i" and 
slightly renamed the project to conform to the way that OSM has, can, does and 
will complete projects (including, but requiring that we use wikis).  BC2020 
seems to have become moribund and ineffective, though I continue to hold out 
high hopes that it can be successful.

OSM actually DOES have clear requirements or feedback, part of those are 
naturally "built in" to crowdsourced projects, part of those need a bit of 
goosing along by prompting volunteers to communicate well (wiki is ONE way, not 
the only way) via simple things like reporting progress and/or continuing to 
sharpen up focus because tagging started out as an early draft, but now is a 
"more complete" or "final" draft.  Sure, any good project wants to start out 
with clear goals (and should) but a modest bit of mid-course correction 
certainly won't prevent successful completion.

> Fine but a couple of maperthons that were organised had data quality issues 
> and no clear guidance about what tags were most valuable.

That's because no QA was planned up front, just like I suggested to do last 
year and into January of this year.  And I'm not boasting, but I did put some 
effort into the richest set of potential tags (harvested from our wikis) than I 
believe anybody else did, and I don't really have any specific interest in the 
project, except that it be a WELL RUN project.  (So I tried very hard to "seed 
it well").  In crowdsourcing, yes, this can be challenging, but communication 
is the lynchpin that allows it.  Wikis, at least in OSM can be and often are a 
critical component of the successful ongoing (status reporting, etc.) and 
completion of projects.

> I could be wrong but I'm not aware of any significant movement on the project.

OSM (worldwide, not "just" in Canada or any particular country) seems to be in 
a communication crisis, where everybody thinks that some sort of 
"secret-special-sauce walkie-talkie" (like GitHub or Slack) will solve 
everything.  No.  While those have their place (let me emphasize, I truly mean 
that) they will continue to Balkanize (fracture) and legally bind (have you 
READ the contracts GitHub and Slack ask you to agree to?!) OSM volunteers far 
past the state of hobble-and-wobble, it will kill us.

Talking about GitHub is like pilot-radio-chatter:  specialized, harmful to 
BUILDING new community (which is CRITICAL in BC2020) and will keep you grounded 
as certain as a hurricane.  OSM Canada knows how to crawl, and even walk.  To 
run, and even fly, especially with BC2020, use what we have.  The fancy stuff 
might (MIGHT!) be used later.

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-de] EU-Urheberrechtsrichtlinie und ihre Folgen für OSM

[Michael Reichert]

Hallo,

Am 21.06.2018 um 01:16 schrieb Michael Reichert:
> *Was können wir tun?*
> Am Karlsruher Stammtisch hatten wir die Idee, als politisches Statement
> einen Teil der Kartenkacheln von tile.openstreetmap.de in den nächsten
> Tagen vorübergehend durch schwarze Kacheln mit einer politischen
> Botschaft zu ersetzen. Es gibt schon grobe Pläne, wie wir das in der
> Konfiguration des Tileservers umsetzen. Dennoch rufen wir zur Mithilfe
> auf. Es ist nicht allein getan, die Konfiguration des Tileservers zu
> ändern. Folgende weitere Dinge sind noch zu tun, bevor wir die schwarzen
> Tiles ausliefern können:
> 
> 1. Es muss eine Seite auf *.openstreetmap.de geben, die erklärt, was am
> Entwurf der Richtlinie schlecht ist und warum die Filterpflicht uns
> genau schadet. Auch ohne Webdesign-Kenntnisse könnt ihr hier mithelfen
> und z.B. den Text formulieren oder Links zu weiteren Seiten zu diesem
> Thema zusammenstellen.
> 
> 2. Gut wäre es, wenn wir den Text auch ins Englische übersetzen könnten,
> falls andere Tileserver-Betreiber und andere Local Chapter der OSMF es
> uns gleichtun wollen.
> 
> 3. Die schwarze Fehlerkachel, eine 256 x 256 Pixel große PNG-Datei muss
> gestaltet werden. Vorschläge werden gerne entgegengenommen.

Vom 4. bis 11. September ist die Copyright Action Week gegen die
EU-Urheberrechtsrichtlinie.

https://de.saveyourinternet.eu/

Am 12. September stimmt das Plenum des Europäischen Parlaments erneut
über den Entwurf ab. Plattformen für die Entwicklung quelloffener
Software sind im Entwurf des Rechtsausschusses jetzt auch ausgenommen.

Die schwarzen Kacheln wurden heute Abend auf für dem deutschen
Tileserver, der vom FOSSGIS e.V. betrieben wird, aktiviert. Neun von
zehn (oder sind es acht von neun?) Anfragen nach einer Kartenkachel
werden wie üblich beantwortet. Die neunte/zehnte wird mit der schwarzen
Kachel beantwortet. Ein erzwungenes Neuladen (oft Strg+R), ggf.
verbunden mit dem Löschen des Caches, führt dazu, dass andere Kacheln
schwarz sind. Serverseitig wird pseudozufällig ausgewürfelt.

https://www.openstreetmap.de/karte.html

Die Startseite von openstreetmap.de hat einen niedrigen schwarzen Banner
am oberen Rand bekommen, der auf
https://www.openstreetmap.de/uf/index.html verlinkt. Dort gibt es
Informationen, warum manche Kacheln schwarz sind.

> Wir werden unsere Serverkonfiguration Betreibern anderer kostenloser
> Tileserver zur Verfügung stellen, damit diese sich ebenfalls für freie
> Geodaten und gegen Uploadfilter aussprechen können.

Wer einen Tileserver betreibt und ebenfalls zufällige Tiles durch eine
Botschaft ersetzt ausliefern möchte, kann folgende Konfiguration
verwenden, wenn er Apache und mod_tile einsetzt:

Im VirtualHost vor den mod_tile-bezogenen Direktiven Folgendes einfügen
(getestet auf Ubuntu und Debian, andere Distributionen haben andere Pfade):

RewriteEngine on
RewriteMap gefiltert "rnd:/etc/apache2/gefiltert.txt"
RewriteCond "${gefiltert:0}" "1"
RewriteRule "^/(.*)(\d).png" "/savetheinternet.png" [PT]

/etc/apache2/gefiltert.txt hat folgenden Inhalt:

0 0|0|0|0|0|0|0|1

Ja, das Leerzeichen gehört so. Die Anzahl der Nullen bestimmt die
Wahrscheinlichkeit, ein normales Tile zu erhalten. gefiltert.txt muss in
/etc/apache2/ (Unterverzeichnis geht vermutlich auch) liegen.

savetheinternet.png sollte im DocumentRoot abgelegt werden. Ihr könnt
das PNG unter
https://wiki.openstreetmap.org/wiki/File:Savetheinternet.png
und das SVG unter
https://wiki.openstreetmap.org/wiki/File:Savetheinternet.svg
herunterladen.

herunterladen.

Viele Grüße

Michael



-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-us] USPS Post Boxes

[Peter Dobratz]

Leif,

What's the next step in your process on this?

I prefer the "operator"="United States Postal Service".  Not only does it
match the sticker on the side of many blue mail boxes (
https://wiki.openstreetmap.org/wiki/File:Post_office_drivethrough_lane.jpg
), it follows the general OSM guideline of not putting abbreviations in
names of things (
https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29
).  The https://www.usps.com/ website seems to use both USPS and United
States Postal Service.

Thanks,
Peter

On Tue, Aug 28, 2018 at 5:02 PM Jack Burke  wrote:

> Because they are labeled "United States Postal Service" with big stickers,
> that's how I've been tagging them.
>
> -jack
>
> --
> Typos courtesy of fancy auto spell technology
>
> On August 28, 2018 4:02:40 PM EDT, Jmapb  wrote:
>>
>> On 8/28/2018 3:31 PM, Leif Rasmussen wrote:
>>
>> Hi everyone,
>> A couple of days ago, I noticed that different post boxes in the United
>> States had different ways of tagging that they were part of the USPS
>> system.  Roughly 60% had "operator"="USPS", 40% "operator"="United States
>> Postal Service", and about 15 similar to "operator"="United States Post
>> Services" or "United States Post Office".  I wanted to make them all the
>> same, so I asked on the OSMUS Slack group about the tags, and most people
>> supported "USPS".  I then proceeded to upload a changeset manually
>> converting 1500 "United States Postal Service" or similar to "USPS".  I
>> should have waited longer before uploading.
>> https://www.openstreetmap.org/changeset/62020302
>> https://overpass-turbo.eu/s/Boq
>> All post boxes in the USPS system now have "operator"="USPS".
>> After uploading, people expressed concern about the choice of "USPS" over
>> "United States Postal Service".  The wiki states that abbreviations should
>> be expanded, "USPS" could be confused with other agencies
>> , and this
>> counted as an automated edit, which should have had better planning with
>> the OSM community.
>> I would now like to propose converting all post boxes with the tag
>> "operator"="USPS" to "operator"="United States Postal Service".  I would
>> also like to add the tag "operator:wikidata"="Q668687" to the post boxes
>> that currently have "operator"="USPS".  Please reply with any feedback or
>> concerns you have with this proposal.
>>
>>
>> Thanks for looping us in, Leif. Haven't made it to the slack group yet,
>> but when I noticed that change I thought to myself "thank the Lord, it's
>> over!" Every time I've tagged a post box I've managed to convince myself
>> that I did it wrong the previous time. So I rotated between "USPS", "usps"
>> and "United States Postal Service" and figured I'd get around to fixing
>> them when my brain settled down. Seeing someone else take the initiative
>> was a relief, despite the understandable grumbling about automated edits.
>>
>> Now that it's done, I'm in favor of making an exception to the
>> no-abbreviations rule for a fixed set of couriers, so sticking with USPS.
>> It's easy to tag and read, and I don't think it's truly ambiguous... if the
>> United States Power Squadrons start a courier service, *they* should be
>> tagged with the fully expanded name.
>>
>> Another reason is that there are plenty of private company post boxes,
>> and I'd like the tagging style to be consistent as possible, with the
>> commonly-used compact versions of their names. I feel operator=UPS,
>> operator=FedEx, operator=DHL will be easier to write, maintain, and read
>> than operator=United Parcel Service, operator=Federal Express, operator=..
>> well, I still can't figure out what DHL actually stands for.
>>
>> Also -- not an issue for postboxes per se, but I've found occasion to tag
>> some some shops with the shipping companies they offer, and the idea of a
>> semicolon-seperated list of fully expanded shipping company names makes me
>> weary.
>>
>> (No problem with adding the operator:wikidata tag.)
>>
>> Thanks, Jason
>>
>>
>> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-ca] GitHub app for BC2020i Challenge

[john whelan]

> Hm, we tried to revive the wiki, a tried-and-true OSM methodology for
doing EXACTLY that.  Is there something wrong with that idea?

No this project was initiated by Stats Canada, but without clear
requirements or feedback about what had been achieved.  The Stats Can side
wasn't dependant on normal OSM mappers but my understanding was it was
hoping to draw in new mappers.

Fine but a couple of maperthons that were organised had data quality issues
and no clear guidance about what tags were most valuable.

I could be wrong but I'm not aware of any significant movement on the
project.

Cheerio John

On 6 September 2018 at 15:58, OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> > Personally I think if the BC2020i is to be revived mappers really need
> some feedback on what has been done and what tags are of interest.
>
> Hm, we tried to revive the wiki, a tried-and-true OSM methodology for
> doing EXACTLY that.  Is there something wrong with that idea?
>
> I've been trying to keep "the embers orange and warm" on this project (via
> its wiki) since January.
>
> https://wiki.osm.org/wiki/WikiProject_Canada/Building_Canada_2020
>
> If there is something wrong with that wiki (John Whelan, you have
> described its history both here in talk-ca and to me via private email any
> number of times), then re-write it.  I think it is at least a start to
> describe what you (Canada) are trying to do, so if it or parts of it are
> useful, use it.
>
> On an upside, there are a lot of data there, (though some of it might be
> junk or outdated), and so as a corollary, on a minor downside, it could be
> said to be loquacious/wordy/overly detailed.  On a MAJOR downside, "BC2020"
> (not suffixed with an "i" as that is rightly declared to be dead) "needs
> reviving."  OK, revive it.  If not via wiki, "because mappers really need
> some feedback" (it DOES mention Active Monitoring tools) and "what tags are
> of interest" (it DOES mention Tag Standardization" and "The data that could
> be mapped"), then HOW?  The answer:  (or at least an excellent one):  use
> our already-built, well-established, good-for-our-community tools which
> WORK.
>
> Go!
>
> SteveA
> OSM Volunteer since 2009
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] GitHub app for BC2020i Challenge

[OSM Volunteer stevea]

> Personally I think if the BC2020i is to be revived mappers really need some 
> feedback on what has been done and what tags are of interest.

Hm, we tried to revive the wiki, a tried-and-true OSM methodology for doing 
EXACTLY that.  Is there something wrong with that idea?

I've been trying to keep "the embers orange and warm" on this project (via its 
wiki) since January.

https://wiki.osm.org/wiki/WikiProject_Canada/Building_Canada_2020

If there is something wrong with that wiki (John Whelan, you have described its 
history both here in talk-ca and to me via private email any number of times), 
then re-write it.  I think it is at least a start to describe what you (Canada) 
are trying to do, so if it or parts of it are useful, use it.

On an upside, there are a lot of data there, (though some of it might be junk 
or outdated), and so as a corollary, on a minor downside, it could be said to 
be loquacious/wordy/overly detailed.  On a MAJOR downside, "BC2020" (not 
suffixed with an "i" as that is rightly declared to be dead) "needs reviving."  
OK, revive it.  If not via wiki, "because mappers really need some feedback" 
(it DOES mention Active Monitoring tools) and "what tags are of interest" (it 
DOES mention Tag Standardization" and "The data that could be mapped"), then 
HOW?  The answer:  (or at least an excellent one):  use our already-built, 
well-established, good-for-our-community tools which WORK.

Go!

SteveA
OSM Volunteer since 2009
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] GitHub app for BC2020i Challenge

[john whelan]

It looks pretty but misses the detail in the magic step then a miracle
occurs.

Currently wind is the cheapest renewable energy source.  Off shore works
well but the central area of North America works fine.  Unfortunately New
York, Toronto, Montreal were all established in relatively wind free areas
many years ago so they need a power grid to get the energy to them.  Wind
also has the advantage of being available when all those office lights in
the buildings were on in the video.

There are a couple of problems with solar, first the cost of connecting to
the grid is quite high.  More than 50% of a home roof top installation
costs are for permits and connections.  That's why OREC.ca likes bigger
roofs and ground solar arrays. The second problem is roof vents, they limit
where solar panels can be placed on the roof.  Currently there are very few
roof vents in OSM to see where solar panels could be placed.  Very few
buildings have enough roof detail to see if the slope is in the right
direction for solar panels.

OREC accept that wind turbines are nice but the most efficient ones today
are big and that means expensive $3-4 million dollars each which they think
they can't affordon a local coop basis.  A wind farm makes sense from a
logistics point of view but a decent wind farm has many turbines, we aren't
talking local here.  The bigger they are the more efficient they are and
the more likely to produce a steady stream of electricity.

 Most are around 499 feet tall, the FAA require extra steps in their
approval process if its higher than 499 feet.  New ones in the pipeline are
850 feet tall.

On the mapping side I haven't seen any feedback on how much detail has been
attached to buildings as part of the BC2020i project.  If anywhere I'd
expect Ottawa to have the richest tag set per building.

Personally I think if the BC2020i is to be revived mappers really need some
feedback on what has been done and what tags are of interest.

Cheerio John

On 6 September 2018 at 11:06, Jonathan Brown  wrote:

> This is cool. Could we not develop a BC2020i challenge similar to the ECCE
> annual challenge? (See McMaster University Team’s winning ECCE 2018 entry:
> https://www.youtube.com/watch?v=yRb_g1llT00=youtu.be=
> PLdgq5G0ox73VEQFJd4No6peb4NP-GFbdU
>
>
>
> Jonathan
>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[OSM-talk-fr] Rencontre mensuelle Bordeaux, contributeurs-trices OSM, lundi 10 septembre, à partir de 19h à Vélocité

[Vincent Bergeot]

Bonjour,

Rendez vous *lundi 10 septembre à 19h à Vélocité, 16 rue Ausone* à 
Bordeaux https://osm.org/go/b~~SkYG_H?m=

Au programme :

  * Qui est qui :)
  * un point sur l'import des données ouvertes de la métropole sur les
bandes et voies cyclables
  * ouverture d'une page sur le wiki pour garder une trace de nos réunions
  * et puis ce que l'on veut ...

Au plaisir,

PS : Voici le lien pour 
s'abonner à la liste : 
https://listes.openstreetmap.fr/wws/subscribe/local-bordeaux
-- 
Vincent Bergeot ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-Kosovo] Fwd: Koment ne konsultimin publik per strategjine e turizmit te K. Prishtine

[Arianit Dobroshi]

On behalf of FLOSSK I've sent the following comments about Prishtina
Municipal Draft Tourism Strategy though which we urge them to make
appropriately licensed promotional content and code available for use on
Wikipedia, OpenStreetMap and elsewhere.

Draft Tourism Strategy for Prishtina in SQ only
http://prishtinaonline.com/drejtorite/kultures-rinise-dhe-sportit/draft-strategjia-e-turizmit



-- Forwarded message -
From: Arianit Dobroshi 
Date: Wed, Aug 29, 2018 at 6:18 PM
Subject: Koment ne konsultimin publik per strategjine e turizmit te K.
Prishtine
To: 
Cc: private , 


I nderuar Yll,

E pash strategjine per zhvillimin e turizmit. Kishit perfshi kete pjese
relevante per FLOSSK-un dhe wikipedianet:

*Ofrimi i informatave të sakta në platforma të hapura në internet. Një nga
mënyrat se si vizitorët marrin informacione gjenerale mbi destinacionin
janë platformat e hapura në internet (p.sh. Wikipedia). Informacionet për
Prishtinën në këto platforma, megjithatë, janë të mangëta dhe shpesh herë
jo të sakta. Sa i përket orientimit, vizitorët kryesisht shërbehen me
platformën “Googlemaps”. Por, edhe në këtë rast, ekziston një shpërputhje
në mes të emrave të rrugëve që figurojnë në ‘Googlemaps’ dhe atyre të
vendosur në pllaka fizike në hyrje të rrugëve. Planifikohet që përmes një
ekipi tëadresohet mungesa dhe asimetra e informatave në këto platforma, si
dhe të bëhet optimizimi i makinave të kërkimit (“searchoptimizationengine”)
në përgjithësi. *

Ky eshte fillim i mire, por ne kerkojme nje trajtim me gjitheperfshires qe
do ta lehtesonte kontributin e komuniteteve perkatese ne platformat e
hapura per ta permiruar permbajtjen per Prishtinen, çofte ne Wikipedia,
OpenStreetMap apo platforma te tjera.

E drejta e autorit pengon shperndarjen e materialit turistik prandaj autori
qe synon shperndarjen e informacionit pa qellim te kompensimit financiar,
sic eshte rasti me Komunen qe shperndane informacion turistik, duhet te
heqe dore nga disa pengesa ligjore qe ne menyre automatike te pavetdijshme
i krijon Ligji per te drejten e autorit.

Materiali qe krijojne organet publike vec financohet nga publiku prandaj
eshte e natyrshme qe t'i kthehet atij pa kompensim shtese; per me teper,
eshte e logjikshme qe qe te lehtsohet shperndarja e materialit qe krijohet
per promovim.

Materiali mund te jene fotografite e monumenteve kulturore dhe te natyres
(shiko fotografite qe jane mbledhe prej komunitetit te wikipedianeve permes
iniciativave Wiki Loves Monuments

dhe Wiki Loves Earth
),
vet Enciklopedia  e Lire Wikipedia, harta e lire OpenStreetMap
 e cila e mbulon Prishtinen shume me
mire se hartat komerciale, guida turistike Wikivoyage
 e cila eshte shume me aktuale se
guidat komerciale etj. Ne momentin qe materiali shkruhet ne anglisht, mund
te kerkojme perkthim nga kontribuesit ne keto projekte ne gjuhet tjera,
p.sh. ato te Evropes Lindore ose edhe dicka ekzotike si japonishtja.

Keto platforma mund te sherbejne si produkte ne vetvete ose per t'u
perdorur per te ndertuar aplikacione dhe materiale derivuese.

P.sh. nje mori fotosh turistike nen licencat e hapura sic jane ato Creative
Commons do te lehtsonin shume shkrimin e guidave turistike ose krijimin e
aplikacioneve, njejt edhe me OpenStreetMap e cila mund te integrohet pa
pagese dhe mund te pasurohet nga kontribuuesit individual.

Ne momentin qe institucioni dhuron material nen licence te hapur dhe
teknikisht te riprodhuheshem nga makina ose mbeshtete ne forma te ndryshme
keto projekte, e perbashkta (commons) rritet duke krijuar baze per
sendertim te metutjeshem te paimagjinueshem nga autori i pare.

Licencat me te njohura jane ato Creative Commons, te cilat mundesojne
shperndarjen me disa restriksione varesisht synimit, lexo per to ketu
https://creativecommons.org/licenses/ dhe ketu
https://en.wikipedia.org/wiki/Creative_Commons_license

*Komuna e Prishtines duhet te bej keto:*

*- Ta licencoj materialin ekzistues turistik qe ka ne pronesi nen nje
licence te hapur.*
*- Te siguroj qe fotot, guidat, hartat dhe softueri qe do te prodhohet ne
te ardhmen do te licencohet nen nje licence te hapur dhe ofrohet ne format
elektronik burimor (source file) te publikuar online.*
*- Ta nxite prodhimin e permbajtjes nga te tjeret nen licenca te hapura
duke mbeshtetur me material burimor nisma si ato te wikipedianve ose
hartografuesve ne OpenStreetMap.*

Nese keni pyetje, mos hezitoni me na shkru.

Jemi te hapur me i shpalose keto ide ma tutje me ekipen qe po e drafton
strategjine.

Me nderime,

Arianiti

Kryetar i bordit ekzekutiv, FLOSSK
Anetar i bordit, Grupi i Perdoruesve te Wikimedianve te Gjuhes Shqipe
___
Talk-Kosovo mailing list
Talk-Kosovo@openstreetmap.org

Re: [Talk-it] dataset MISE distributori

[Sergio Manzi]

Secondo me dovrebbe essere "operator = *NomeDiPersona*", lasciando il tenant ai 
soli casi in cui il proprietario dell'impianto, noto, sia diverso dall'operator.

Ma alla fine, ci interessa sapere a quele tenant l'operator paga l'affitto 
dell'impianto a fine mese?

E con la GDPR come la mettiamo? Andiamo a casa del tenant a chiedergli se gli 
va bene essere pubblicato (al 99% no...)?

Ciao,

Sergio


On 2018-09-06 19:12, LvdT wrote:
> Se facessi le cose a modo mio, taggerei semplicemente:
> brand = Eni
> tenant = *NomeDiPersona*
>
> Voi cosa fareste?
>
> Ciao,
> Irene.
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-ie] Raths / ringforts

[Colm Donoghue]

bivallate is the technical term for a double ring fort

The Archaeological survey people might have some insight on the
rath/dún/lios/caiseal category

Colm

On Thu, 6 Sep 2018, 17:36 Brian Hollinshead,  wrote:

> Some time ago I had discussion the Archaeological survey Ireland concerning
> our possible use of their open data. At that time their cc-by ?  was not
> quite enough open for OSM use as there were two sticking points. Dacor has
> ironed these out in the meantime and kindly made sample acceptances
> available.
>
> I will now re-open discussion with them.
>
> On Thu, 6 Sep 2018 at 17:22, moltonel 3x Combo  wrote:
>
> > On 06/09/2018, Rory McCann  wrote:
> > > I mapped a lot with historical=earthworks earthworks=rath. A few years
> > > brianh came up with a tagging scheme for historic objects like that in
> > > Ireland, and that was the tagging for ringforts, so I used that. I have
> > > no strong attachment to it, and would be willing to change to something
> > > else.
> >
> > Thanks. I've gone ahead with some earthworks->fortification retaging
> > in Kilkenny : https://www.openstreetmap.org/changeset/62348383
> >
> > * I've removed the " (rath)" that was sometimes appended to the name.
> > It should probably go in name:ga but I haven't the skill.
> > * Some notes refer to the ringfort as "plough-leveled", maybe that's a
> > better wording than "razed" for the ringfort_type key ?
> > * It would be nice to tag forts that consist of multiple rings, like
> > https://www.openstreetmap.org/way/538754476, but I'm not sure that
> > ringfort_type=dun is the right choice.
> > * Not all earthwork is a ringfort, see
> > https://www.openstreetmap.org/way/536904479 - I guess this should also
> > change from earthworks=motte to fortification_type=hill_fort, like
> > https://www.openstreetmap.org/way/357271010 ?
> >
> >
> > > The Archeological Survey of Ireland has all these (and more!) mapped,
> > > and I believe there's some attempt to ask the Dept Culture, Heritage &
> > > Gaeltacht to open that out, but nothing yet. That would certainly aid
> > > mapping.
> > >
> > > https://www.archaeology.ie/archaeological-survey-ireland
> >
> > Is it worth pinging them again ?
> >
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
> >
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-it] dataset MISE distributori

[LvdT]

>Il discorso di brand e name si può soltanto risolvere con una buona
conoscenza dell’attuale situazione (survey), mentre map roulette ti fa
vedere situazioni casuali che quasi mai conosci di persona, quindi il
risultato può essere solo peggio di prima. 

A me può tornare utile per vedere cosa c’è da fare in zone in cui posso
andare a verificare.

Prima di mettermi a fare qualcosa vorrei però capire un po’ cosa si è deciso
sull’utilizzo dei tag. In particolare:

1) C’è una lista di come andrebbero inserite le diciture nei brand? Magari
si potrebbe mettere su wiki sotto IT:Key:brand (che al momento non esiste).
In particolare non ho capito come è stata risolta la questione delle pompe
bianche...

2) Effettivamente annosa la questione del tag name, la wiki lo farebbe
mettere solo quando la stazione di servizio ha un nome “individuale”, anche
io sarei per evitare ripetizioni di tag ove possibile.

3) operator e tenant, tenant è il nome del proprietario della pompa, mentre
operator mi pare di capire sia per la società che gestice?

Faccio un esempio pratico: vedo qui vicino un distributore con brand=“Agip
Eni”, è il tag corretto? Non si chiama soltanto Eni la compagnia? Come
operator c’è “Impianto Agip di *NomeDiPersona*”, che mi pare più una cosa da
tenant.

Se facessi le cose a modo mio, taggerei semplicemente:

brand = Eni
tenant = *NomeDiPersona*

Voi cosa fareste?

Ciao,
Irene.



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-talk-ie] Raths / ringforts

[Brian Hollinshead]

Some time ago I had discussion the Archaeological survey Ireland concerning
our possible use of their open data. At that time their cc-by ?  was not
quite enough open for OSM use as there were two sticking points. Dacor has
ironed these out in the meantime and kindly made sample acceptances
available.

I will now re-open discussion with them.

On Thu, 6 Sep 2018 at 17:22, moltonel 3x Combo  wrote:

> On 06/09/2018, Rory McCann  wrote:
> > I mapped a lot with historical=earthworks earthworks=rath. A few years
> > brianh came up with a tagging scheme for historic objects like that in
> > Ireland, and that was the tagging for ringforts, so I used that. I have
> > no strong attachment to it, and would be willing to change to something
> > else.
>
> Thanks. I've gone ahead with some earthworks->fortification retaging
> in Kilkenny : https://www.openstreetmap.org/changeset/62348383
>
> * I've removed the " (rath)" that was sometimes appended to the name.
> It should probably go in name:ga but I haven't the skill.
> * Some notes refer to the ringfort as "plough-leveled", maybe that's a
> better wording than "razed" for the ringfort_type key ?
> * It would be nice to tag forts that consist of multiple rings, like
> https://www.openstreetmap.org/way/538754476, but I'm not sure that
> ringfort_type=dun is the right choice.
> * Not all earthwork is a ringfort, see
> https://www.openstreetmap.org/way/536904479 - I guess this should also
> change from earthworks=motte to fortification_type=hill_fort, like
> https://www.openstreetmap.org/way/357271010 ?
>
>
> > The Archeological Survey of Ireland has all these (and more!) mapped,
> > and I believe there's some attempt to ask the Dept Culture, Heritage &
> > Gaeltacht to open that out, but nothing yet. That would certainly aid
> > mapping.
> >
> > https://www.archaeology.ie/archaeological-survey-ireland
>
> Is it worth pinging them again ?
>
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [OSM-talk-ie] Raths / ringforts

[moltonel 3x Combo]

On 06/09/2018, Rory McCann  wrote:
> I mapped a lot with historical=earthworks earthworks=rath. A few years
> brianh came up with a tagging scheme for historic objects like that in
> Ireland, and that was the tagging for ringforts, so I used that. I have
> no strong attachment to it, and would be willing to change to something
> else.

Thanks. I've gone ahead with some earthworks->fortification retaging
in Kilkenny : https://www.openstreetmap.org/changeset/62348383

* I've removed the " (rath)" that was sometimes appended to the name.
It should probably go in name:ga but I haven't the skill.
* Some notes refer to the ringfort as "plough-leveled", maybe that's a
better wording than "razed" for the ringfort_type key ?
* It would be nice to tag forts that consist of multiple rings, like
https://www.openstreetmap.org/way/538754476, but I'm not sure that
ringfort_type=dun is the right choice.
* Not all earthwork is a ringfort, see
https://www.openstreetmap.org/way/536904479 - I guess this should also
change from earthworks=motte to fortification_type=hill_fort, like
https://www.openstreetmap.org/way/357271010 ?


> The Archeological Survey of Ireland has all these (and more!) mapped,
> and I believe there's some attempt to ask the Dept Culture, Heritage &
> Gaeltacht to open that out, but nothing yet. That would certainly aid
> mapping.
>
> https://www.archaeology.ie/archaeological-survey-ireland

Is it worth pinging them again ?

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

Re: [OSM-talk-be] N30 relation fixed (was: National Road relation: does order matter?)

[André Pirard]

On 2018-09-03 21:59, Nathan Monfils wrote:

Op ma 3 sep. 2018 om 20:03 schreef André Pirard :
Op zo 2 sep. 2018 om 22:54 schreef Nathan Monfils 

Hello!

I was doing some editing on the N30 near Liège, when I noticed that its
relation was completely unordered, with ways near the city center being
next
to ways much further south (see relation `124374`).

The wiki defines a relation as an *ordered list*, yet only mentions order
for
bus lines. Is there a need for the road relations to be ordered
correctly?

Regards,

Nathan Monfils

On 2018-09-03 00:24, Jo wrote:

for route=road relations order doesn't matter much. It's impossible to
sort them according to any meaningful criterion.

Op ma 3 sep. 2018 om 20:03 schreef André Pirard :

A meaningful criterion to sort a route is so that two adjacent ways of it
share one same end node.
In other words, that the route is ordered the way you travel it without
interruptions.
That's what the "sort" buttons of JOSM do.
And, beside finding a segment more easily, the schema of the route made by
JOSM shows the gaps (missing pieces).
And in particular it will show if the road is circular.
For example, if you sort the N30, you will see a gap between Boulevard de
Fraipont and Avenue de la Libération.
And 16 other gaps in total.

Last time I spoke of routes with a Potlatch user, he told me he couldn't
sort routes.
I don't know about ID and that's quite a time ago.

The N30 should be sorted and corrected.
I will let Nathan do it if he's busy with it.

Amitiés,

André.

Polyglot


On Monday, September 3, 2018 8:09:28 PM CEST Jo wrote:

The "problem" with N roads is that they are not linear features, they
split, recombine, have dangling dead ends, roundabouts and so on.

Yes, you can group some of the elements, but the next time you sort, other
groups may be formed, so it's arbitrary.

Jo

I fixed the N30 relation the way I described.
I chose the order from Liège to Ardennes (holiday departures are happier 
than comeback ;-)).

That's the element order, down the list in JOSM relation editor.
Roundabouts are indicated by role "forward".
First way set to follow when traveling in route's direction.
Second way set to follow in the other direction.
JOSM shows them nicely with sidings like this



splits/recombines like Boulevard de Beaufraipont are normally like 
roundabout.


Basically, global sort doesn't change my roundabouts and splits.
But sort only sorts what is sortable and is only guaranteed as a local tool.
Hence, a global sort doesn't find a common northern node for the huge split
starting at Boulevard Raymond Pointcarré and ending in prongs.
And so it includes only one branch of it and it throws the other one to 
the end.


All the best,

André.



On 2018-09-03 21:59, Nathan Monfils wrote:

After looking into it further, I can only agree. I added the missing members
back (one way and a few junctions that were probably overlooked by previous
mappers), but every roundabout and double road "cuts off" the automatic
ordering by JOSM.
It seems to consider that a loop breaks the relation order entirely and
doesn't attempt to follow it any further.

I still pushed the changes since they contain a few added members, but I think
the N30 (and other N roads) will have to stay unsorted, unless JOSM's sorting
mechanism starts taking geographical proximity into account instead of
strictly checking the end nodes.

Regards,

Nathan Monfils



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

Re: [Talk-it] Problema mailing list

[Sergio Manzi]

Eccomi qui, sono io il "colpevole" del patatrac!

In realtà non mi sento tanto colpevole: il problema è che il mio dominio usa 
una "feature" di sicurezza e anti-spam che è "allo stato dell'arte" (si chiama 
DMARC e chi è curioso può travare info su https://dmarc.org o su Wikipedia), 
mentre il software che OSM utilizza per le mailing-list non è aggiornato per 
poter interoperare con i domini che usano questa feature. Tra l'altro credo che 
le mail di Yahoo siano "a rischio" sotto questo aspetto.

Adesso e temporaneamente, ho "ucciso" il mio DMARC e spero di non creare altri 
problemi nell'immediato, ma penso che ci sia un problema reale ed attuale che 
OSM deve affrontare...

Un caro saluto a tutti e mi scuso per essere stato involontaria causa dei 
problemi.

Sergio


P.S.: per favore avvisatemi se ancora ci sono "rogne" con il mio dominio...


On 2018-09-05 20:42, Stefano wrote:
>
>
> Il giorno mer 5 set 2018 alle ore 19:31 Daniele Forsi  > ha scritto:
>
> Il giorno mer 5 set 2018 alle ore 19:11 Gabriele Sani ha scritto:
>
> > +1 ho riattivato, ma è come se fossero stati mandati troppi messaggi da 
> me (se ho interpretato bene bounces)
>
> hai interpretato male: gmail ha "rimbalzato" un messaggio quasi
> certamente perché lo ha considerato SPAM e mailman ci ha sospeso da
> talk-it
>
> il messaggio che io non ho ricevuto è questo, giudicate voi se i
> filtri di gmail hanno fatto un buon lavoro
>
> 
> https://lists.openstreetmap.org/pipermail/talk-it/2018-September/064222.html
>
>
> Si, è il "vecchio" problema di autenticazione delle email, la disiscrizione 
> di massa era successa solo una volta...
> Nulla di grave :-)
>  
>
>
>
> --
> Daniele Forsi
>
>
> Stefano
>  
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-se] Konstgjorda ortsnamn med "och"

[Andreas Vilén]

Gogogo. Osm ska reflektera verkligheten och inte SCB:s statistiska indelning. 
Tätorterna är en bra vägledning men ingen absolut regel.

/Andreas

Skickat från min iPhone

> 5 sep. 2018 kl. 14:46 skrev Ture Pålsson :
> 
> Varje gång jag tittar på kartan över mitt närområde blir jag lite irriterad 
> på ortsnamnet "Österhagen och Bergliden": 
> https://www.openstreetmap.org/node/2381453578 . Namnet verkar vara något som 
> förekommer i SCB:s tätortsstatistik [1] t.o.m. 2010, men har försvunnit 2015 
> (eftersom tätorten vuxit ihop med Bro) och jag gissar att ingen någonsin sagt 
> att hen bor i Österhagen och Bergliden. Jag skulle vilja ta bort noden och 
> ersätta med två, placerade med ledning av t.ex. Lantmäteriets numera 
> användbara öppna data. Eller förstör jag någons fina databastillämpning då? 
> Fast det verkar ju dumt att OSM:s databas ska vara en inaktuell kopia av 
> SCB:s databaser... Iofs ska vi väl inte vara en kopia av LM:s data heller, 
> men det är åtminstone inte estetiskt fult... Vad säger folk?
> 
> [1] 
> https://www.scb.se/hitta-statistik/regional-statistik-och-kartor/geodata/oppna-geodata/tatorter/
> 
> 
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se

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

Re: [Talk-ca] GitHub app for BC2020i Challenge

[Jonathan Brown]

This is cool. Could we not develop a BC2020i challenge similar to the ECCE 
annual challenge? (See McMaster University Team’s winning ECCE 2018 entry: 
https://www.youtube.com/watch?v=yRb_g1llT00=youtu.be=PLdgq5G0ox73VEQFJd4No6peb4NP-GFbdU
 
 
Jonathan 

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

Re: [Talk-gb-westmidlands] September meeting

[Eike Ritter]

Dear all,

is there a meeting today?

Best wishes,

Eike




signature.asc
Description: OpenPGP digital signature
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

[Talk-cz] Zápis z brněnské hospody (SOTM, založení organizace)

[Miroslav Suchy]

Zápis z včerejšího piva U Kormidla:

* vop má zapsaný pozdní příchod :)

* nové jméno pro PhotoDB2 - probírali jsme možné kombinace OSM, mapy, Photo, 
DB. Nakonec jsme si řekli, že snad bude
lepší název úplně jiný a nesouvisející. Načež padly návrhy:
  - Fody
  - Phody
  - FieldPhotos
  Můžete hlasovat co se vám líbí: https://doodle.com/poll/5kb5dnue35wbs5y8
  Tom se pak vašemi preferencemi může a nebo nemusí řídit :)

* SOTM 2018 - nejvyšší čas něco plánovat. Tak jsme vybrali datum 17. listopadu 
(dle Cimrmana, významné datum ať se to
dobře pamatuje). S tím, že v sobotu by byli přednášky a v neděli případně 
nějaký mapovací workshop. V každém případě by
to bylo v Brně nebo blízkém okolí. Pokud plánujete přijet, ta budu rád když mi 
dáte nezávazně vědět v:
   https://doodle.com/poll/iri3mpczufydww75
Podle počtu zájemců bych pak vybral místo, abychom se tam vlezli.
Kdo byste chtěli přednášet (bloky budou asi po 30 minutách), tak mi prosím 
napište, budu chystat program.

Jedna z věcí, kterou bychom na SOTM 2018 vyřešit je založení české pobočky OSM. 
Takže si prosím přečtěte návrh stanov co
posílal Tom K. a připadně připomínky se snažte vyřešit před konferencí. První 
hlasování musí být fyzicky. Později to
půjde i elektronicky, ale ustanovující schůze musí být in-persona. Takže pokud 
chcete být členy ode dne 0, tak si prosím
naplánujte cestu.
Pokud někdo chcete kandidovat do rady nové organizace, tak prosím pište VOPovi. 
On to bude sbírat. Kandidáti by se měli
na konferenci dostavit a představit se ostatním o následně si z kandidátů 
zvolíme radu.

Mirek

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[OSM-talk] Sharing a new tool -- Visualize Change

[Nate Smith]

Hello OSM Community -

Sending along an update from HOT about some new work we’ve recently rolled
out. It’s a new tool we’ve built and started to use to make time-based
animations of OSM edits. This has been helpful for us to share short
animations of change over time with colleagues and partners.

It’s open and available to use at https://visualize-change.hotosm.org.

Give it a spin. Share your creations on Twitter with the hashtag #hotosm
#visualizechange!

You can read more at
https://www.hotosm.org/updates/launching-visualize-change/. It’s all based
on OSM QA Tiles. If you have ideas for ways you'd like to use it, or if you
want to jump into help contribute, the code and open issues are on Github
at https://github.com/hotosm/visualize-change.

Nate

-- 
Nate Smith
Humanitarian OpenStreetMap Team
@nas_smith 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] Evacuation Routes

[Eric H. Christensen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

-‐‐ Original Message ‐‐‐
On September 6, 2018 9:51 AM, James Umbanhowar  wrote:

> Would this fit the route relation model better if we used the following
> tagging scheme
>
> route:road
> network:MD:hurricane
>
> or something similar?

When this was discussed on the tagging list scheme wasn't brought up.  I was 
trying to keep it as generic as possible to keep it simple, to make it flexible 
for all kinds of evacuation routes (not just hurricanes), and to make it work 
globally.

What would be the benefit of using a network be?

Eric
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsFcBAEBCAAQBQJbkTcRCRCAdqveAkuz0QAArHYP/2Xb4ROaEv9ueUSGT3Sw
TQHFqyDVXR8ZAYOC7C9ttOwWFQQU0DuRF8cYpENDsnPduzjVgWdrkpQslsHP
arUcqMU9tx+RoMIJSemnaCGrEWND+mFas0r4c+nJqLlVWwfCTHpEVDSo5jum
6HhsxSS62sUL2rHdaMyzPZN79Nbcruof8Z3pRvbie1x0mGv9cGr9DVC7OFPG
CguGOuXgd2cxqYgiv1IoAwh6djBPIpe52Hxoq6RHmdxPg1LnUg37Xi7beDeG
HkmCoOgNpUxXehgoPiYor33gdj2PTzrS7mwfYqisL5G+0/dIZ81U/I3yEOMZ
HDWVDoWceqhbto9TT+EHj6U/taNCXLBZE9EYcRmt/lQfSW1M25+pywbVqcZ7
wBplc0wqEUlEugqP8mPaAmtXuBKk/PFiz7wGpN3/ZCD+243PnP67DzKIkQH+
JHa93ez92wkOe81sfk66dh8Qf2M+wWFtxvhFCpgRKW2BT4WDPuKGG+pi78th
MnI35Dh9OK3qeUUJgfQEKXfqXYPMQKeIN7EZC9WwyeaisJXZ+gyRtw/pPLJF
gc9sB9SOsfI3U3RwjxN8kTTsWsDKIQszgKWo8iebGrJEQm+im6UP54myjM14
MvN0N+1P9Guw/1TtxwxXk/SKZYrewRmqG+9+4Ow0lnkcZfdJUQUlHS5uLlKB
yM8r
=fIqM
-END PGP SIGNATURE-


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

Re: [Talk-cz] Openstreetmap.cz, vrstva chybných rozcestníků - cyklo rozcestníky

[Tom Ka]

Pocitam ze s tim neco budu delat viz. i ta nedavna diskuze s
(ne)ignorovanim cyklo. Davam si na todo list po preklopeni PhotoDB2 na
produkci.

Mirku mas ten zapis z piva s jmenem projektu?

Bye

On Thu, Sep 6, 2018, 13:20 majka  wrote:

> Dávám k úvaze, zda na openstreetmap.cz ve vrstvě chybných rozcestníků
> také zvolna nezačít rozlišovat od sebe turistické rozcestníky a cyklo
> rozcestníky barvou, jako to děláme u rozcestníků vyfocených (příklad tady
> ). Případně
> zda by nebylo lepší je z chybných zcela vynechat (tedy jen rozcestníky s
> pouze bicycle=yes, jako je ten chybějící na tom odkazu) a do mapy
> nezobrazovat jen cyklo rozcestníky, které se spárují.
>
> Ve "vyfocených" územích nám ty cyklo rozcestníky v téhle vrstvě trochu
> začínají přidávat šum, a taky nafukují velikost v těch souborech gpx, které
> se vytvářejí.
>
> Netuším, jestli chceme uživatele vyzývat k focení stejně, jako u
> turistických rozcestníků. Řekla bych, že se soustavným zpracováním těch
> fotek momentálně nikdo z nás nezabývá, resp. maximálně si autor ty  svoje
> fotky vždy nějak zpracuje sám. Neříkám nezadávat do OSM, nebo nefotit (a
> neukazovat v mapě), ale možná nevykazovat momentálně jako stejnou chybu,
> jako u turistických rozcestníků (tedy chybějící foto a/nebo ref).
>
> Majka
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-us] Evacuation Routes

[James Umbanhowar]

Would this fit the route relation model better if we used the following
tagging scheme

route:road
network:MD:hurricane

or something similar?  


On Wed, 2018-09-05 at 23:06 +, Eric H. Christensen wrote:
> I recently finished an update to the evacuation routes feature[0],
> turning it into a relation (route).  I'll be working on adding
> hurricane evacuation routes to areas I'm familiar with (Maryland,
> Hampton Roads area of Virginia, and Northeast North Carolina) but I
> encourage others to add evacuation routes to their local areas as
> well.
> 
> Currently, JOSM doesn't recognize this route type and I don't think
> they're being rendered on any third-party software but I'm hoping
> once enough data is in the system we'll be able to show a reason for
> rendering such information.
> 
> Thanks,
> Sparks
> 
> [0] https://wiki.openstreetmap.org/wiki/Tag:route%3Devacuation
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us


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

Re: [Talk-it] dataset MISE distributori

[Martin Koppenhoefer]

sent from a phone

> On 6. Sep 2018, at 13:43, Cascafico Giovanni  wrote:
> 
> Ho messo su una challenge [1] in maproulette per la risoluzione dei 
> nomi/brand.



penso sia del tutto inappropriato e ti chiederei di togliere la challenge, in 
quanto simula/promette il contributo di sapere locale/intervento umano ma non 
può tenere la promessa.

Il discorso di brand e name si può soltanto risolvere con una buona conoscenza 
dell’attuale situazione (survey), mentre map roulette ti fa vedere situazioni 
casuali che quasi mai conosci di persona, quindi il risultato può essere solo 
peggio di prima.


Ciao, Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] Openstreetmap.cz, vrstva chybných rozcestníků - cyklo rozcestníky

[Václav Kroupar]

Mě osobně vyhovuje, že mám všechny chybějící rozcestníky. Prostě na místě
vyfotím vše. Občas zapomínám vyplnit číslo rozcestníku (stydím, stydím).
-- Původní e-mail --
Od: majka 
Komu: talk-cz@openstreetmap.org
Datum: 6. 9. 2018 13:20:41
Předmět: [Talk-cz] Openstreetmap.cz, vrstva chybných rozcestníků - cyklo
rozcestníky
"
Dávám k úvaze, zda na openstreetmap.cz(http://openstreetmap.cz) ve vrstvě
chybných rozcestníků také zvolna nezačít rozlišovat od sebe turistické
rozcestníky a cyklo rozcestníky barvou, jako to děláme u rozcestníků
vyfocených (příklad tady
(https://openstreetmap.cz/#map=16/49.0500/14.4435=dNGB)). Případně
zda by nebylo lepší je z chybných zcela vynechat (tedy jen rozcestníky s
pouze bicycle=yes, jako je ten chybějící na tom odkazu) a do mapy
nezobrazovat jen cyklo rozcestníky, které se spárují.



Ve "vyfocených" územích nám ty cyklo rozcestníky v téhle vrstvě trochu
začínají přidávat šum, a taky nafukují velikost v těch souborech gpx, které
se vytvářejí. 




Netuším, jestli chceme uživatele vyzývat k focení stejně, jako u
turistických rozcestníků. Řekla bych, že se soustavným zpracováním těch
fotek momentálně nikdo z nás nezabývá, resp. maximálně si autor ty  svoje
fotky vždy nějak zpracuje sám. Neříkám nezadávat do OSM, nebo nefotit (a
neukazovat v mapě), ale možná nevykazovat momentálně jako stejnou chybu,
jako u turistických rozcestníků (tedy chybějící foto a/nebo ref).




Majka

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz
"___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[Talk-ht] OSM pour agroforesterie

[Fred Moine]

Bonjour,

J’espère que tout le monde va bien. J’envoie un message comme une bouteille
à la mer : )

Je suis entrain de reprendre un dossier pour une formation OSM pour l'UNOGA
(université d'agroforesterie à la Grande Anse en Haïti). Initialement
c'était pour continuer les formations OSM qu'on avait faites après Matthew
2016 (OSM pour la gestion des risques inondation, et glissement de terrain).
pour mémoire:
http://www.potentiel3-0.org/index.php/en/11-sample-articles/43-demo-article-6

Mais plus je prépare la mission qui va avoir lieu en septembre sur Jérémie.
Plus je découvre qu'ils font de l'agroforesterie et de la préservation de
la biodiversité un élément important pour la gestion des risques.

Pour les soutenir au mieux dans leur travaux, je dois m'adapter rapidement.
L'UNOGA et le Jardin des cayes font un herbier en ce moment sur le terrain
et me demandent de collecter des points GPS des différentes espèces pour
les aider.
Ils veulent à terme, avec une université à Montréal, faire des
modélisations pour voir quel type d’espèce ils peuvent ou doivent préserver
en priorité avec l'intégration des données météo, glissement terrain,
changement climatique J’espère que j'ai bien compris leur demande car
elle vient pimenter la préparation de la formation

Donc la demande (comme l'agroforesterie n'est pas mon domaine) :

- Connaitriez vous des organismes qui ont développés des questionnaires
terrain avec ODK
Et par chance en intégrant des tags OSM : )  on veut les former à
OpenMapKit ou GeoOdk.
- Si vous avez des pistes ou contact pour que je puisse creuser la
thématique pour répondre au mieux à leur demande.

Voila on va les accompagner de façon volontaire sur ce projet et sujet
qu'on pense important pour Haïti. Ce sont des partenaires impressionnant de
par leur impact, leur motivation et ceux malgré le manque de moyen. Comme
quoi parfois ce n'est pas forcement qu'un problème d'argent.

Volontairement vôtre, FredM pour l'équipe Potentiel3.0

PS: on avait pensé à mettre un serveur Geopoppy, mais le niveau n'est pas
encore là pour se permettre de mettre cela en place sur le terrain.
___
Talk-ht mailing list
Talk-ht@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ht
Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour 
traduire les messages.

Re: [Talk-us] Talk-us Digest, Vol 130, Issue 8

[Jay Johnson]

Here are the North Carolina nuclear evacuation routes.

https://www.ncdot.gov/travel-maps/maps/Pages/evacuation-routes.aspx

The hurricane routes are here:

https://www.ncdot.gov/travel-maps/maps/Documents/coastal-evacuation-routes.pdf




On Thu, Sep 6, 2018 at 8:03 AM  wrote:

> Send Talk-us mailing list submissions to
> talk-us@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/talk-us
> or, via email, send a message with subject or body 'help' to
> talk-us-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> talk-us-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-us digest..."
>
>
> Today's Topics:
>
>1. Re: Evacuation Routes (Rihards)
>
>
> --
>
> Message: 1
> Date: Thu, 6 Sep 2018 13:38:35 +0300
> From: Rihards 
> To: "talk-us@openstreetmap.org" 
> Subject: Re: [Talk-us] Evacuation Routes
> Message-ID: 
> Content-Type: text/plain; charset=utf-8
>
> On 2018.09.06. 02:06, Eric H. Christensen wrote:
> > I recently finished an update to the evacuation routes feature[0],
> turning it into a relation (route).  I'll be working on adding hurricane
> evacuation routes to areas I'm familiar with (Maryland, Hampton Roads area
> of Virginia, and Northeast North Carolina) but I encourage others to add
> evacuation routes to their local areas as well.
>
> That page says "Cycle routes or bicycle route are named or numbered or
> otherwise signed routes. May go along roads, trails or dedicated cycle
> paths."
>
> Is that correct?
>
> > Currently, JOSM doesn't recognize this route type and I don't think
> they're being rendered on any third-party software but I'm hoping once
> enough data is in the system we'll be able to show a reason for rendering
> such information.
> >
> > Thanks,
> > Sparks
> >
> > [0] https://wiki.openstreetmap.org/wiki/Tag:route%3Devacuation
> --
>  Rihards
>
>
>
> --
>
> Subject: Digest Footer
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
> --
>
> End of Talk-us Digest, Vol 130, Issue 8
> ***
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Evacuation Routes

[Eric H. Christensen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

‐‐‐ Original Message ‐‐‐
On September 6, 2018 6:38 AM, Rihards  wrote:
> That page says "Cycle routes or bicycle route are named or numbered or
> otherwise signed routes. May go along roads, trails or dedicated cycle
> paths."
>
> Is that correct?

*sigh* That was a copy/paste error.  I've fixed that, or at least started to 
fix that.  Thanks for bringing that to my attention.

Eric
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsFcBAEBCAAQBQJbkRsXCRCAdqveAkuz0QAAlJ4QALEGqEhHdvfosxSPK93K
wjZHSHaTWCZrlGLx6bNmQJtiuSKWiTlt8eVmilws5FnnS9SUlRdsGX6SxVlb
q8JfxqedQa/EEgwgArkxcBvYF8oDcpG1CiRrRJxq7WDdbcLlbSfy7AhIZ25K
ED57YWyXzNH7L6szdqaQrD1AEONWFbd4BAqzgw/Ul0xhdbWU2Ty5RYBtL/8P
yp9DfVKQdhXBQAaG9k0JuhEsTmj7WrtSYsSyCsmSj4P5JXr1ZwtmZqh8AeCM
ycRH9sWE5LfgK3HiABx+I2ozlgNCQeDS/vE/FL/HLYd/+iZ8GFk22Lto2sFa
geijeacbkowRGvFe3o+v1ThqWLKPe+3Xvt0W/0qzZxlsAxGLzCSUIVAMGwyV
yb2gTNUGRN7mLKX2I4ZG1Mn6K86sP1EquOYwELB0yGLa7jl6D2zn8c/5CBZl
dDjurBtnE6ldN/pQfsgLWVbgr6doPvaejX5VeN8OdEbyYDBWODqbppPpSrZ8
2p7Ql0nYcMzJBrD2ndsFVI/0/QG0KjyHqVpEdzmcfqEP4dSFJWVw7Yy+hij1
dmkfO1sUfdeNSM1lbvyFcMLQk//iIRmtiHLFaGeWqDr+hHTEJcPEt7Hc/Aw1
9jm1swiWTvTg4fg2Jrm4QMOjKW1M9k11yGkYUqORQGj0gTYwIe7MQXza1gi/
vhYz
=y1Pi
-END PGP SIGNATURE-


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

Re: [Talk-it] dataset MISE distributori

[Cascafico Giovanni]

Questa è la query di estrazione...

[out:json][timeout:60];
area(3600365331)->.searchArea;
(
  node["amenity"="fuel"]["fixme"~"name"](area.searchArea);
  way["amenity"="fuel"]["fixme"~"name"](area.searchArea);
  relation["amenity"="fuel"]["fixme"~"name"](area.searchArea);
);
out center;
>;
out skel qt;

Oooops! forse ho sbagliato a mettere quel ">;".. mo lo tolgo-


Il giorno 6 settembre 2018 13:53, Andrea Musuruane  ha
scritto:

> C'è qualche problema con i distributori taggati come area (e non come
> nodo): compaiono una volta per ogni vertice del poligono che lo compongono
> (e senza tag).
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] dataset MISE distributori

[Andrea Musuruane]

C'è qualche problema con i distributori taggati come area (e non come
nodo): compaiono una volta per ogni vertice del poligono che lo compongono
(e senza tag).

Ciao,

Andrea

On Thu, Sep 6, 2018 at 1:44 PM Cascafico Giovanni 
wrote:

> Ho messo su una challenge [1] in maproulette per la risoluzione dei
> nomi/brand.
>
> [1] http://maproulette.org/mr3/browse/challenges/3161
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] dataset MISE distributori

[Cascafico Giovanni]

Ho messo su una challenge [1] in maproulette per la risoluzione dei
nomi/brand.

[1] http://maproulette.org/mr3/browse/challenges/3161
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-cz] Openstreetmap.cz, vrstva chybných rozcestníků - cyklo rozcestníky

[majka]

Dávám k úvaze, zda na openstreetmap.cz ve vrstvě chybných rozcestníků také
zvolna nezačít rozlišovat od sebe turistické rozcestníky a cyklo
rozcestníky barvou, jako to děláme u rozcestníků vyfocených (příklad tady
). Případně
zda by nebylo lepší je z chybných zcela vynechat (tedy jen rozcestníky s
pouze bicycle=yes, jako je ten chybějící na tom odkazu) a do mapy
nezobrazovat jen cyklo rozcestníky, které se spárují.

Ve "vyfocených" územích nám ty cyklo rozcestníky v téhle vrstvě trochu
začínají přidávat šum, a taky nafukují velikost v těch souborech gpx, které
se vytvářejí.

Netuším, jestli chceme uživatele vyzývat k focení stejně, jako u
turistických rozcestníků. Řekla bych, že se soustavným zpracováním těch
fotek momentálně nikdo z nás nezabývá, resp. maximálně si autor ty  svoje
fotky vždy nějak zpracuje sám. Neříkám nezadávat do OSM, nebo nefotit (a
neukazovat v mapě), ale možná nevykazovat momentálně jako stejnou chybu,
jako u turistických rozcestníků (tedy chybějící foto a/nebo ref).

Majka
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-us] Evacuation Routes

[Rihards]

On 2018.09.06. 02:06, Eric H. Christensen wrote:
> I recently finished an update to the evacuation routes feature[0], turning it 
> into a relation (route).  I'll be working on adding hurricane evacuation 
> routes to areas I'm familiar with (Maryland, Hampton Roads area of Virginia, 
> and Northeast North Carolina) but I encourage others to add evacuation routes 
> to their local areas as well.

That page says "Cycle routes or bicycle route are named or numbered or
otherwise signed routes. May go along roads, trails or dedicated cycle
paths."

Is that correct?

> Currently, JOSM doesn't recognize this route type and I don't think they're 
> being rendered on any third-party software but I'm hoping once enough data is 
> in the system we'll be able to show a reason for rendering such information.
> 
> Thanks,
> Sparks
> 
> [0] https://wiki.openstreetmap.org/wiki/Tag:route%3Devacuation
-- 
 Rihards

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

Re: [OSM-talk-ie] Raths / ringforts

[moltonel 3x Combo]

On 05/09/2018, Donal Hunt  wrote:
> https://en.wikipedia.org/wiki/Ringfort
>
> In Irish language  sources
> they are known by a number of names: *ráth* (anglicised *rath*), *lios*
>  (anglicised *lis*; cognate with Cornish
>
> (...)
>
> Based on the above definitions, nodes should tagged with ring_fort but
> detailed mapping could use ráth and lios.

From that wikipedia article it seems that ráth is just the irish word
for ringfort, there doesn't seem to be added information ? For ráth vs
lios, see below.

I don't care much about ring_fort vs ringfort, but the later is what's
currently in the db and wiki.

> I assume a relation tagged with
> ringfort would be appropriate for locations that have the ráth and lios
> mapped.

The distinction between ráth (the actual ring) and lios (the inner
area) is interesting, but I couldn't find any mapping that made that
distinction. Similarly, we rarely map the building walls separately
from the building rooms. The vast majority of ringforts are mapped as
ways. The ~10 that are mapped as relations seem to be so because a
townland boundary follows a portion of the ring.

If we want to do detailed mapping, there are some characteristics that
we could identify:
* does it use (at least some) stones or just earth ? See also
https://en.wikipedia.org/wiki/Earthworks_(archaeology). The wiki's
tagging scheme starts with usage (fortification), we could refine
further with nature (earthwork).
* Has it been razed ? In my reviews I found a lot of ringforts that
got flattened (typically for agricultural reasons) but that are still
visible as ground discoloration on imagery. I don't want to start an
"abandoned railway" debate, but I guess there's a whole spectrum of
"still exists".
* height, public access, signposted, paid access, etc.

How about ringfort_type=rath/caiseal/dun/razed to differentiate
between earth, stone, large, and destroyed ringforts ?

Dun Aengus (on Aran More) is currently tagged as 'historic=castle
castle_type=defensive'. Should we switch it to the above-mentioned
scheme ? Any other comparable fort we should look at ?

> p.s. I have no other knowledge / opinion other that want I've read above. I
> do think they are cool and worth mapping. 50,000 is a lot of work!!!

~2500 done, 47500 to go :)

I've got other things on my plate, but from now on I'll try to map
ringforts when I stumble upon them.

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

Re: [Talk-us] NYC Name Vandalism

[Andy Townsend]

On 06/09/2018 01:56, Alan Brown wrote:
... I suspect the OSM community is not culturally disposed to that 
form of moderation. So I will ask about a different approach.


One thing the OSM community _is_ culturally disposed to is people trying 
things to see if they work, and in order to do there there's no need to 
do it on a planet-wide basis.


A place to start might be consuming diffs, and if you're looking for 
"something that processes diffs that is relatively easy to understand" 
then https://github.com/zverik/regional might be a place to start; an 
example of how that can be used is at 
https://github.com/SomeoneElseOSM/mod_tile/blob/zoom/openstreetmap-tiles-update-expire#L159 
.  In that example "trim_osc.py" is called to remove data from a diff 
file based on geographical location prior to inclusion in a rendering 
database; you could create something similar based on some other 
criteria*. 
https://wiki.openstreetmap.org/wiki/User:SomeoneElse/Ubuntu_1804_tileserver_load#Updating_your_database_as_people_edit_OpenStreetMap 
is the elevant bit of some "set up a tile server" instructions that call 
that; you could use those to create a tile server incorporating your 
filtering and see how it compared to "real OSM" after a few days.


Best regards,

Andy


* perhaps initially just a simple obscenity filter for place names, not 
withstanding that that won't catch e.g. things drawn with water and 
roads to form letters - I've seen a couple of those recently.



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

Re: [Talk-us] NYC Name Vandalism

[Simon Poole]

OSM changesets or even the diffs only contain the changes to objects,
while in the simple case (somebody vandalising the name tag on NYC) that
may be enough to determine that something is "bad" for example messing
up a motorway exit will require you to actually apply (in one way or the
other) the changes to the existing data, or even the changes from
multiple changesets. Then naturally you will have edits that undo
previous bad edits that need to be handle some way too (this creates a
potential for conflicts, as the fix may be a substantial amount of time
later). 

I suspect some of the above is why Mapbox uses a different granularity
grouping of changes for their review process (see the SotM talk by Lukas).

In any case all of the above potentially lead to your private fork of
the planet getting out of sync real fast with the original, implying
that applying diffs will become more problematic over time.  So you
wouldn't be able to take you fixed and known good planet fork, apply
only good diffs, and expect to be able to continue to do that for a year
or so.

IMHO the only thing that could really work in the OSM model is reverting
real fast in the -original- dataset.

Naturally there is the other aspect that we want our contributors to
gain experience and become better mappers over time. You are only going
to get that if leave the opportunity to make mistakes open and don't
robo-fix everything that goes wrong

Simon


Am 06.09.2018 um 02:56 schrieb Alan Brown:
> Hi,
>
> Perhaps I didn't express it clearly, but my interest was in the idea
> that certain. rather limited changelists could be flagged for
> moderation before they are put into main dataset.  There will always
> be things that seem like they should be blocked, but are actually
> appropriate.   In the interest of having the most accurate data, I'm
> not convinced this form of moderation can't have a role.  As I
> understand it, the virtue of OSM is to allow anyone to contribute
> accurate, detailed local knowledge about the places they know about;
> however, there's no value in having junk in the database for even a
> moment, if it can be avoided.  Place names are usually verifiable
> facts, even disputed place names.  So you don't want the open nature
> of OSM to compromise accuracy, or a quest for accuracy to discourage
> people from contributing accurate information.
>
> I said my peace; I suspect the OSM community is not culturally
> disposed to that form of moderation. So I will ask about a different
> approach.
>
> In my case, I've seen editing errors that affected motorway
> connectivity (not vandalism), that were made and corrected within a
> couple hours.  Pretty good - except our planet file was in that two
> hour window.  I want to avoid these errors, without getting caught in
> the errors of the next two hour window.
>
> I'm not sure if Mapbox or others use a process like this, but this is
> what I can imagine:
>
> PLANETcur is the current planet file
> PLANETprev is the last used planet file
> CHANGEcur-prev is a comprehensive list of changelists between the two
> datasets
>
> A particular consumer of OSM data can automatically scan
> CHANGEcur-prev and/or PLANETcur for potentially troubling content,
> according to their own criteria.  In their local copy, if they detect
> something they do not want to accept - offensive place names,
> incomplete topology - they can attempt to revert - in their local copy
> only! - recent changes that violate their criteria.  They accept
> whatever mistakes their "reversion" algorithm makes.  The identified
> "questionable changelists"  can be submitted back to the OSM community
> to review and revert, but always by a human.
>
> My hope is that I am being completely unoriginal, and I can cobble
> together existing tools quickly. How unoriginal am I?
>
> I am looking over the osmcha.mapbox.com page, and saw reference to a
> utility called "osm-compare":  
> https://github.com/mapbox/osm-compare/blob/master/comparators/README.md
> - which has an obscenity filter.  If I understand this correctly,
> osm-compare flags changelists for review, osmcha.mapbox.com allows
> people to review the flagged datasets and reverse bad edits.  Could
> someone define osm-compare filters that produce results that can be
> automatically pulled into a local copy?
>
> (If a changeset has been reviewed by a second person - can that
> information be provided).
>
> All I want is something that allows me to be a little bit more
> conservative in accepting edits, without requiring complex processes
> or large resource.  A little insight would be appreciated.
>
> Thanks,
> Alan
>
>
>
>
>
>
>
> On Wednesday, September 5, 2018, 7:52:46 AM PDT, Simon Poole
>  wrote:
>
>
> osmcha (osmcha.mapbox.com) already does most of this. While detecting
> vandalism in general is difficult, edits like those in question are easy
> to detect and small in number.
>
> IMHO it really isn't an issue with openstreetmap in this case, as even
> with the 

Re: [OSM-talk-fr] OSMAnd et les boîtes aux lettres de la Poste

[Julien Lepiller]

Le 2018-09-05 18:34, Gwenaël Jouvin a écrit :

Bonjour,

Il y a quelques jours, j’ai remarqué plusieurs contributions avec des
ajouts de plusieurs .
Étant donné que les boîtes aux lettres privées ne sont pas forcément
hyper-prioritaires, j’étais surpris d’en voir autant apparaître.

Après un coup de StreetView (je m’en fouette encore ;-) ), mes
craintes étaient fondées : c’était bien des boîtes (de dépôt) de la
Poste qui avaient la mauvaise valeur de clef.

J’ai contacté quelques contributeurs qui ont tous en commun d’avoir
OSMAnd en clef  sur le changeset :
https://www.openstreetmap.org/changeset/61799892
https://www.openstreetmap.org/changeset/61725926
https://www.openstreetmap.org/changeset/58855160

Je me demande donc s’il n’y a pas un biais, voire une erreur dans le
module de contribution de cette application ; je ne peux pas en juger
car je ne l’utilise pas pour ça.
Si quelqu’un en sait plus sur le sujet…


En regardant sur l'appli, si on sélectionne le type de POI « boite aux 
lettres », on obtient un « amenity=letter_box », et si on sélectionne le 
type de POI « boîte aux lettres », on obtient un « amenity=post_box ». 
C'est ridicule que la différence se fasse sur un accent, donc je suis 
allé sur le weblate 
(https://hosted.weblate.org/projects/osmand/phrases/fr/) pour corriger. 
Voilà ce qui sera affiché à la prochaine mise à jour :


boite aux lettres -> post_box
boite aux lettres privée -> letter_box

osmand est sensible à la différence entre boite et boîte, donc j'ai 
aussi ajouté cette variante (si j'ai bien compris, on peut ajouter des 
variantes en les séparant par des points-virgules).


N'hésitez pas à corriger si j'ai fait une bêtise !



Merci !

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


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

Re: [OSM-talk] Error on OSM

[Oleksiy Muzalyev]

Hi Stadia Arcadia,

I added lighting masts for the stadium Stade Raymond-Kopa ( 
https://wiki.openstreetmap.org/wiki/Tag:tower:type=lighting ). I 
indicated height as 50 meters by estimation from Wikimedia photos of 
this stadium. I also added some trees and a parking.


It seems that the tribune Tribune Coubertin indeed has got the square 
shape jugging from this ground photo 
https://commons.wikimedia.org/wiki/File:Tribune-Colombier.jpg made in 
January 2018. But on all the aerial imagery available in the JOSM editor 
it does not have the square shape yet.


If you need to update it urgently you may order the orthorectified 
aerial image from say https://www.dronebase.com/ , and then the map 
could be updated accordingly. Did you mean that you cannot do it 
yourself because you could not find the up to date orthorectified image? 
Or you cannot update the map due to some physical reason? Or you just do 
not know how to do it? If the latter than you can watch tutorials on 
youtube where everything is explained clearly. Search for something like 
"mapping in josm" at youtube.


Best regards,
Oleksiy


On 05.09.18 16:56, Stadia Arcadia wrote:
Hi, "Tribune Colombier" of Stade Raymond-Kopa now has the same size as 
"Tribune Coubertin". Is now has a square shape. The old stand has been 
replaced with a new one. Who can fix this? I'm a member of OSM, but I 
can't get it fixed. Who can do it for me? I'd really appreciate that. 
Thanks for the help already.


https://www.openstreetmap.org/#map=19/47.46040/-0.53094=N


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



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