Re: [Talk-de] Kreuz Werl - seltsame Spurnutzung

[Martin Scholtes]

Am 15.10.2019 um 01:23 schrieb Martin Koppenhoefer:
>> On 14. Oct 2019, at 15:00, Florian Lohoff  wrote:
>>
>> Merke: Eine Geschwindigkeitsbegrenzung gilt bis sie aufgehoben wird (Und
>> eine Einmündung hebt sie nicht auf)
>
> die Geschwindigkeitsbegrenzungen gelten für die „Strecke“, d.h. wenn man die 
> Strecke verlässt gelten sie nicht mehr. Praktisch sind an allen Stellen wo es 
> zu Unklarheiten kommen könnte normalerweise Schilder.

Eben nicht. Die Diskussion gab es bereits im Forum in Zusammenhang mit
BAB-Abfahrten. Den auch dort verlässt man die Strecke, jedoch gilt
weiterhin die durch vorherige Zeichen erklärte Geschwindigkeitsbeschränkung.

Gruß
Martin


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

Re: [Diversity-talk] Your talk submission for SotM 2019

[Heather Leson]

Hey I shared a draft a few weeks ago . Will merge my content

Heather

On Mon, 14 Oct 2019 at 23:08, Rebecca Firth 
wrote:

> Hey everyone,
>
> Thanks to those who took a look already. I am planning to post this on
> Wednesday so if you want to input, please do it before then!
>
> Thanks,
>
> Rebecca
>
> On Wed, Oct 9, 2019 at 11:49 AM Rebecca Firth 
> wrote:
>
>> Hi All,
>>
>>
>>
>> As promised, sharing a draft on the diversity session blog. I think this
>> would be best to post as an OSM Diary and submit to WeeklyOSM. I’m also
>> coordinating on if it can go on the HOT website. Please add your thoughts
>> and ideas by the end of the weekend so we can move forward and post it?
>>
>>
>> https://docs.google.com/document/d/1BjUHky9N71IjMGYCYrwhEUTmu3BZOTNb-WaIxPzqbmY/edit
>>
>>
>> Thanks,
>>
>>
>>
>> Rebecca
>>
>> On Mon, Sep 30, 2019 at 4:41 PM Rebecca Firth 
>> wrote:
>>
>>> Hi there,
>>>
>>> I took a load of notes, but unfortunately a bit snowed under this week
>>> with quite a variety of project deadlines -- is it okay if I add them in by
>>> Wednesday?
>>>
>>> Thanks!
>>>
>>> On Mon, Sep 30, 2019 at 4:30 PM Heather Leson 
>>> wrote:
>>>
 Dear colleagues, thank you so much for this discussion.

 I started the draft here - https://pads.ccc.de/bwWXryNYXv

 Rebecca, I think you took some notes as well?  would you be able to
 fold these in?

 Can we aim to publish on Saturday?

 Heather
 Heather Leson
 heatherle...@gmail.com
 Twitter/skype: HeatherLeson
 Blog: textontechs.com


 On Thu, Sep 26, 2019 at 10:40 PM Miriam Mapanauta 
 wrote:

> Hi to all,
>
> So great to see you last week, I was very happy to see so many people
> joining and participating in the Panel. Many people is asking me if it was
> recorded because they would love to watch it, I am aware it was not
> recorder but I suggest that we write a blog with the concerns and actions
> we heard we should be taking in the future. I would be glad to co-write
> something in the coming weeks.
>
> Big hug from sunny Mexico!
>
> Miriam
>
> On Tue, Sep 17, 2019 at 2:46 PM Rory McCann 
> wrote:
>
>> Sat. lunchtime or 2nd break is fine with me.
>>
>> See yous soon! :)
>>
>> On So, Sep 15, 2019 at 6:20 PM, Heather Leson 
>>
>> wrote:
>> > Dennis, we would love for you to join us. Please add your name to
>> the
>> > hackpad.
>> >
>> > All - would it be possible to meet at lunch or second break on
>> > saturday to talk through the plan.
>> >
>> > See you soon
>> >
>> > Heather
>> > Heather Leson
>> > heatherle...@gmail.com
>> > Twitter/skype: HeatherLeson
>> > Blog: textontechs.com
>> >
>> >
>> > On Sun, Sep 15, 2019 at 5:40 PM Dennis Raylin Chen
>> >  wrote:
>> >> Hi Heather,
>> >>
>> >> If you need a East Asia perspect,
>> >>
>> >> Maybe I could help.
>> >>
>> >> Sorry for the late reply.
>> >>
>> >> Dennis Raylin Chen
>> >>
>> >>
>> >>
>> >> Heather Leson  於 2019年9月13日 週五
>> >> 09:17 寫道：
>> >>> Hirray. So if folks can add their names to the chart, this will
>> >>> help. Maybe we could lunch on saturday to plan.
>> >>>
>> >>>
>> >>> Heather
>> >>>
>> >>> On Fri, 13 Sep 2019, 07:27 Gertrude Namitala,
>> >>>  wrote:
>>  Hello Heather,
>> 
>>  I will help out. Sorry for delay in response.
>> 
>>  Kind regards,
>>  Gertrude
>> 
>>  On Sun, 8 Sep 2019, 20:07 Heather Leson, 
>>
>>  wrote:
>> > HI folks, I heard back from Rebecca and Patricia. they will
>> help
>> > out. We would very much like to engage others. Let me know if
>> you
>> > would like to be involved.  We will need the following:
>> >
>> > 4 or 5 helpers (low prep, just help lead a discussion)
>> > an OSM Diary. Happy to cowrite with you
>> >
>> > Our allies at the Mozilla Diversity and Inclusion mailing list
>> > suggested a format. I think it is helpful. I put the notes and
>> > format draft here. Edits welcome
>> >
>> > https://pads.ccc.de/bwWXryNYXv
>> >
>> > See you soon
>> >
>> > Heather
>> >
>> > Heather Leson
>> > heatherle...@gmail.com
>> > Twitter/skype: HeatherLeson
>> > Blog: textontechs.com
>> >
>> >
>> > On Tue, Sep 3, 2019 at 6:47 PM Heather Leson
>> >  wrote:
>> >> Dear colleagues,
>> >>
>> >> I hope that your summer was grand.
>> >>
>> >> I am researching formats for this. One thing that might help
>> us
>> >> is to tackle what is inclusive language and what are some of
>> the
>> >> measures to improve diversity - 

[talk-ph] Redefining Philippines road classifications [was: Revisiting road classifications]

[Jherome Miguel]

About a week since I presented the first version of the proposed road
classifications and their correspondences, I looked back on the DPWH
documents that defines the road classifications for the Philippines, and
the previous road classes are rather like this:

*Expressway
*National primary road
**North-South Backbone
**East-West Laterals
**Other Roads of Strategic Importance
*National secondary road
*National tertiary road
*Provincial road
*City/municipal road
*Barangay road

Actually, the new classifications are fundamentally the same, except that
the subcategories of national primary roads have been reduced to two, based
on number allocation:

*Main routes (N1-N49)
*Other primary routes (N50-99)

Given that, I see that the present classification we have been using really
works fine, except that we need to better describe some classifications,
for these reasons:

* The primary category needs to be better defined, as it seems to have been
overused, and we should restrict this to some primary national roads, and
all secondary routes (perhaps except for N120, as part of AH26). We have
discussions back in 2009 to restrict the primary classification to national
roads, but it seems to have stalled.
* We might need to cut down the routes tagged as trunk, and I am
considering to have it used only on the primary routes (1-2) digits, with a
handful of exceptions

>From those points I made, I get into this modified proposal:

Rural:
*Motorway - expressways
*Trunk - major primary national roads (1-2 digit routes), that connect
major cities and of strategic importance.
*Primary - less important national roads, secondary national roads (3-digit
routes)
*Secondary - provincial roads, and minor arterial roads in municipalities
*Tertiary - other roads that connect barangays with each other and the
secondary network
*Unclassified - other non-residential rural roads, such as those serving as
the only connection to an isolated sitio/purok or barangay
*Residential - residential streets

Urban:
*Motorway - expressways
*Trunk - major through route through a city or metropolitan area, usually a
primary national road (e.g. EDSA), all of Route 120 (as western alternate
alignment of AH26 through Metro Manila)
*Primary - other major urban routes, usually a secondary national road.
*Secondary - minor urban arteries, connects 3 or more barangays or
districts, and not a numbered national road
*Tertiary -
**collector roads inside barangays or districts, usually narrow and with
traffic calming features (meandering alignments, humps, low speeds)
**other roads connecting barangays and districts with each other and the
secondary network. Usually non-contiguous, and has the same characteristics
as mentioned above.
*Unclassified - non-residential street that does not fit the tertiary
classification.
*Residential - residential streets wide enough for cars

In addition, we should remove the living street classification, as
Philippine traffic law has no equivalent to it, and better retag those
according to the mapper's judgment.

We haven't began any discussions about this since I presented the first
proposal, so we need to get through this.
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [talk-au] Suburban Tunnel at Sydney Central Station

[Andrew Harvey]

I'm okay with disused or construction, until we know it's completely gone
or replaced. Better to leave it there rather than deleted it helps prevent
someone else might just add it back in later without checking on the ground
first.

On Tue, 15 Oct 2019 at 00:02, Luke Stewart 
wrote:

> G'day,
>
> As of 13/10/19, part of the suburban tunnel at Central station has been
> closed off of public access due to Metro works (
> https://www.openstreetmap.org/#map=19/-33.88344/151.20682). I originally
> changed the access tag from "customers" to "no" on the affected segments,
> but am wondering whether it may be appropriate to delete the element all
> together. My though processes is as there are various other tunnels that
> are closed but blocked off like this one, it should remain with access=no
> until such time that we can confirm they are demolished (i.e. when the new
> walkway opens in a few years).
>
> What do you think? Thanks.
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[OSM-ja] brandの標準的なタグに関して

[OKADA Tsuneo]

初めまして。岡田と申します。

ちまちまと入力しているマッパーです。

1つ質問があります。
「brandの標準的なタグ」というのはどこでどなたが設定されているものなのでしょうか？
最近セブン-イレブンのタグのアップグレードの改善提案があり、内容を見ると
最新化の提案内容が「+ brand:wikipedia=en:7-Eleven」
となっていました。
en:じゃなくて、ja:だろうと思うのですが、誰に言うものだろうかと思いまして。

あと、三菱東京UFJ銀行も三菱UFJ銀行にならないかなと思うのですが、
どこかで変更できるのでしょうか？

-- 
岡田常雄(OKADA Tsuneo)
tsuneo.ok...@gmail.com
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset

[Kathleen Lu via legal-talk]

The additional guidelines are OSM-specific:
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines

On Mon, Oct 14, 2019 at 4:58 PM Lars-Daniel Weber 
wrote:

> Sorry, this was a typo. Of course I mean houses in both cases:
>
> Let's say you're creating a map of Western, taking houses from OSM in
> Germany and houses from proprietary data from all other countries, since
> OSM is incomplete here. Isn't this a mixture on the same layer?
>
> Also, when starting from a Planet file, there are no regional cuts.
>
> Are those guidelines additional rules to the ODbL? I thought, ODbL is a
> generic databank license and not OSM specific.
>
>
> *Gesendet:* Montag, 14. Oktober 2019 um 19:57 Uhr
> *Von:* "Kathleen Lu via legal-talk" 
> *An:* "Licensing and other legal discussions." <
> legal-talk@openstreetmap.org>
> *Cc:* "Kathleen Lu" 
> *Betreff:* Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible
> licensed dataset
> The reference to countries come from the Regional Cuts Guideline (and then
> the later Collective Database Guideline), in case that was not clear.
> I don't see how roads and houses (do you mean building footprints?) would
> be "mixture on the same layer" or why the layer matters since they're
> different data types...
>
> On Mon, Oct 14, 2019 at 8:33 AM Lars-Daniel Weber <
> lars-daniel.we...@gmx.de> wrote:
>
>> From: "Kathleen Lu via legal-talk" 
>> > Lars-Daniel already said that they are kept in separate columns and not
>> > de-duplicated. There is no requirement that, in order to function as a
>> > Collective Database, data types may not be used together to create a
>> > Produced Work. To the contrary, the guidance is that the most axiomatic
>> > Produced Work, a global map, may be created from multiple Collective
>> > Databases consisting of different data types and/or different countries.
>>
>> Hmm... but doesn't this violate "Horizontal Layers" Guideline?
>>
>> Let's say you're creating a map of Western, taking roads from OSM in
>> Germany and houses from proprietary data from all other countries, since
>> OSM is incomplete here. Isn't this a mixture on the same layer?
>>
>> I think, there's no difference in this guideline between small and large
>> scale.
>>
>>
>>
>>
>> ___
>> legal-talk mailing list
>> legal-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/legal-talk
>
> ___ legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset

[Lars-Daniel Weber]

Sorry, this was a typo. Of course I mean houses in both cases:

 

Let's say you're creating a map of Western, taking houses from OSM in Germany and houses from proprietary data from all other countries, since OSM is incomplete here. Isn't this a mixture on the same layer?


 

Also, when starting from a Planet file, there are no regional cuts.


Are those guidelines additional rules to the ODbL? I thought, ODbL is a generic databank license and not OSM specific.

 

 


Gesendet: Montag, 14. Oktober 2019 um 19:57 Uhr
Von: "Kathleen Lu via legal-talk" 
An: "Licensing and other legal discussions." 
Cc: "Kathleen Lu" 
Betreff: Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset



The reference to countries come from the Regional Cuts Guideline (and then the later Collective Database Guideline), in case that was not clear.

I don't see how roads and houses (do you mean building footprints?) would be "mixture on the same layer" or why the layer matters since they're different data types...

 


On Mon, Oct 14, 2019 at 8:33 AM Lars-Daniel Weber  wrote:

From: "Kathleen Lu via legal-talk" 
> Lars-Daniel already said that they are kept in separate columns and not
> de-duplicated. There is no requirement that, in order to function as a
> Collective Database, data types may not be used together to create a
> Produced Work. To the contrary, the guidance is that the most axiomatic
> Produced Work, a global map, may be created from multiple Collective
> Databases consisting of different data types and/or different countries.

Hmm... but doesn't this violate "Horizontal Layers" Guideline?

Let's say you're creating a map of Western, taking roads from OSM in Germany and houses from proprietary data from all other countries, since OSM is incomplete here. Isn't this a mixture on the same layer?

I think, there's no difference in this guideline between small and large scale.




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

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




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

Re: [Talk-it] Ospedali, ambulance_station e altro

[Martin Koppenhoefer]

sent from a phone

> On 14. Oct 2019, at 12:03, Fra Mauro  wrote:
> 
> Ovviamente la situazione ottimale sarebbe mappare entrambe le cose


+1, io utilizzerei amenity=hospital per l’ospedale e l’azienda si potrebbe 
mettere in operator.


Ciao Martin 



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

Re: [Talk-de] Kreuz Werl - seltsame Spurnutzung

[Martin Koppenhoefer]

sent from a phone

> On 14. Oct 2019, at 15:00, Florian Lohoff  wrote:
> 
> Merke: Eine Geschwindigkeitsbegrenzung gilt bis sie aufgehoben wird (Und
> eine Einmündung hebt sie nicht auf)


die Geschwindigkeitsbegrenzungen gelten für die „Strecke“, d.h. wenn man die 
Strecke verlässt gelten sie nicht mehr. Praktisch sind an allen Stellen wo es 
zu Unklarheiten kommen könnte normalerweise Schilder.

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

Re: [Talk-ca] weeklyOSM #481 2019-10-01-2019-10-07

[Jarek Piórkowski]

Thanks for the summaries, Weekly Team!

Of particular interest should be the upcoming release of a game that
takes in data from OSM, which might sometimes result in edits adding
fake data for sake of having data in the game, as we saw with Pokémon
Go:

"The Scandinavian gaming website IGN Nordic provides some insight
about the upcoming augmented reality game Minecraft Earth. The map in
the game is based on OpenStreetMap. Minecraft’s creative director
recommends that players join OSM for editing, something that people
with Pokémon GO in mind may hear with mixed feelings. The Guardian
featured Minecraft Earth in article titled “Minecraft Earth is coming
– it will change the way you see your town” and included three
sections about OSM." - weeklyOSM

"Where are the parks, where are the trails, where are the sidewalks,
what streets are closed, open, what are the opening hours of all this?
We ingest all of that, and we turn it into Minecraft. We re-ingest the
whole world once every month, we re-ingest every part of the world,
and then reflect that in the game."
- 
https://nordic.ign.com/switch/29645/interview/18-things-we-just-learnt-about-minecraft-and-minecraft-earth

"It’ll give you information about areas that are not so nice, like
really shady clubs. We use these tags to generate a blacklist of where
not to place items"
- 
https://www.theguardian.com/games/2019/oct/01/minecraft-earth-launch-games-microsoft-augmented-reality

Thanks,
--Jarek


On Sun, 13 Oct 2019 at 06:29, weeklyteam  wrote:
>
> The weekly round-up of OSM news, issue # 481,
> is now available online in English, giving as always a summary of all things 
> happening in the openstreetmap world: 
> http://www.weeklyosm.eu/en/archives/12448/
>
> Enjoy!
>
> Did you know that you can also submit messages for the weeklyOSM? Just log in 
> to https://osmbc.openstreetmap.de/login with your OSM account. Read more 
> about how to write a post here: 
> http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm
>
> weeklyOSM?
> who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
> where?: 
> https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
> ___
> Talk-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

Re: [OSM-legal-talk] map drawn based on OSM tiles

[Kathleen Lu via legal-talk]

I don't think the analogy is quite right.
The Geocoding Guidelines say:

Geocoding Results can be latitude/longitude pairs (as typical in forward
Geocoding Results), and/or full or partial addresses and/or point of
interest names (as typical in reverse Geocoding Results).
Latitude/longitude pairs may come from a “Direct Hit” -- in which case the
data returned will exactly match the data of a feature in the geo-database
used for geocoding -- or it may be an “Indirect Hit”, in which case the
data is inferred or derived from other features, but does not directly
match any feature in the database. The most common type of indirect hits
are interpolated addresses.

For example: Suppose a Geocoding user queries “120 Main St, Anytown, Big
State, USA” and there is a node in the geo-database for that address. A
Geocoding Result consisting of the lat/lon of that node would be a Direct
Hit. However, suppose instead the database contains nodes for 150 Main St
and 110 Main St, but not 120 Main Street. A Geocoder might return a point
in between in between the two known nodes as an estimate of the requested
location. This point (an interpolated result) would be an Indirect Hit.

In the section you quoted, it says "Geocoding Results are an insubstantial
extract **or** contain no OSM data" (emphasis added). So *sometimes*
there's no OSM data, but that's when the results are interpolated. Other
times, individual Geocoding Results (and in certain circumstances as
described in detail in the guidelines, certain types of collections of
Geocoding Results) are insubstantial.

I don't think tracing from a physical printout is the same as
interpolating. It's more like a really basic trivial transformation.

But like I said, based on the usecase you described, I agree I think all
you need to do attribute, just based on different reasoning.

-Kathleen


On Mon, Oct 14, 2019 at 7:59 AM Lars-Daniel Weber 
wrote:
>
> According to community guideline for "Geocoding", I'm not using original
OSM data in my new map at all. Since I've drawn lines from paper drawn on
an Produced Work of OSM data, I don't have any of the original OSM elements
in my final dataset, which are in the OSM dataset.
>
> So, I just need to credit OpenStreetMap as decribed in Section 4.3 of the
ODbL, since it's a Produced Work.
>
>
> > Users of a navigation application send an address search query to a
> > cloud-based Geocoder. The Geocoder has access to two separate map
> > databases, one of which contains solely OSM data. The other database
> > contains non-OSM data. If the address is accurately found in the OSM
> > database, the location is sent back to the navigation application. If
> > the address is not found in the OSM database, then the other database is
> > searched, and that result is returned. (The same example applies when
> > the third party database is searched before the OSM database or when
> > they are searched concurrently.) The OSM-based Geocoding Results are an
> > insubstantial extract or contain no OSM data and thus do not trigger
> > share-alike obligations and can be stored together with the
> > non-OSM-based Geocoding Results with no impact on the non-OSM-based
> > Geocoding results, so long as the aggregated collection of results does
> > not contain the whole or a substantial part of the OSM database. The
> > cloud-based Geocoder is, however, required to credit OpenStreetMap as
> > described in Section 4.3 of the ODbL.
>
> Gesendet: Montag, 07. Oktober 2019 um 20:05 Uhr
> Von: "Kathleen Lu" 
> An: "Licensing and other legal discussions." 
> Cc: "Lars-Daniel Weber" 
> Betreff: Re: [OSM-legal-talk] map drawn based on OSM tiles
> > Thus, assuming the shapefiles are essentially the equivalent of
>>
>> > simplified OSM border shapefiles, the shapefiles are covered by ODbL.
>>
>> Actually, it's like 40% OSM borders (hard borders, like roads, rivers,
topography and administrative stuff) and 60% own borders, which don't
appear in OSM. BUt those borders wouldn't make OSM any better, since
they're specific for the current task.
>>
>
> My view would be the OSM borders are ODbL. Just because it's one
shapefile doesn't mean all of the data in the shapefile has to be under one
license. If the other borders are not border types that are in OSM that you
have traced, ODbL does not implicate them per the Collective Database
Guideline.
>
>>
>> > Now, it sounds like you're not tracing very much, so it's possible that
>> > you have traced fewer than 100 features in which case your tracing is
>> > insubstantial
>> >
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline
>>
>> Actually, I've traced more than 100 features, but the "extraction is
non-systematic and clearly based on your own qualitative criteria" - okay,
not on my one, but on the one who draw the overlay with the pen.
>>
>
> It's possible that your extraction is insubstantial, though I can't say
definitively. But I don't think that you need a definitive answer on

Re: [Talk-es] Importaciones Catastro

[Jordi Miró Ferrer]

No lo recuerdo bien, pero creo que yo tenía un problema similar. Lo solucioné 
editando highway_names.csv con el bloc de notas. Si lo hacía con LibreOffice o 
Excel, me daba error en algún punto (no recuerdo si en el mismo paso que el 
tuyo). Además, cuando modificaba "highway_names.csv", si tenía que eliminar el 
nombre de alguna vía (Polígono XX, por ejemplo), solamente borraba el nombre 
"Polígono XX"; no eliminaba toda la fila.

Ya dirás.


De: Jorge Sanz Sanfructuoso 
Enviat el: dilluns, 14 d’octubre de 2019 17:54
Per a: Discusión en Español de OpenStreetMap 
Tema: Re: [Talk-es] Importaciones Catastro

Tiene que ser algo del CSV que guarda y no soporta como comentas. Pasa el CSV a 
ver si vemos que puede suceder.

Saludos.

El lun., 14 oct. 2019 a las 17:44, Joaquim 
(mailto:jpux...@gmail.com>>) escribió:
Hola,

 Estoy preparando la importación de Alaior, en Menorca (07002) y,
una vez revisados los nombres de las calles intento hacer la segunda
pasada del programa catatom2osm y se aborta por un error: Error al
cargar el archivo CSV '07002/highway_names.csv'

 Si lo hago sin modificar el archivo highway_names.csv la segunda
vuelta se realiza sin problemas. Para editar el csv he usado la hoja de
cálculo de LibreOffice como en anteriores ocasiones (otros municipios)
en las que no tuve problemas. La versión de catatom2osm es la 1.2dev (la
misma que en otras ocasiones).

 Supongo que al abrir y guardar el programa csv se produce algún
cambio que no soporta el programa de importación.

 ¿Alguien puede ayudarme a solucionarlo?

Muchas gracias

Joaquim


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


--
Jorge Sanz Sanfructuoso - Sanchi
Blog http://jorgesanzs.es/
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-hr] Pomoc oko oznacavanja zona pokrivenosti

[Darko Boto]

Na koji način radite tu vektorizaciju? Postoje li negdje upute?

On Mon, Oct 14, 2019 at 1:11 PM hbogner  wrote:

> DGU HOK, US topo, Orbview su gotovi. DGU DOF i DGU RGI su preostali.
>
> DOF je hitniji od RGI, ali svaka pomoć je dobrodošla. :)
>
>
> On 14. 10. 2019. 13:01, Janko Mihelić wrote:
> > Evo ja ću probati srediti RGI
> >
> > pon, 14. lis 2019. u 10:23 hbogner  napisao je:
> >
> >> Treba mi pomoć oko označavanja zona pokrivenosti DGU podlogama
> >>
> >> Na osm-hr blogu su dva članka sa linkovima na wms servise DGU-a
> >>
> >> -
> >>
> >>
> https://osm-hr.org/2019/06/04/pravo-koristenja-mreznih-usluga-prostornih-podataka-drzavne-geodetske-uprave/
> >> -
> >>
> >>
> https://osm-hr.org/2019/07/11/objavljen-digitalni-ortofoto-drzavne-geodetske-uprave-2018/
> >>
> >> Trebaju nam poligoni koji označavaju pokrivenost određenim podlogama kao
> >> na
> >>
> >>
> https://github.com/osmlab/editor-layer-index/tree/gh-pages/sources/europe/hr
> >>
> >> Projekt je privremeno forkan u osm-hr pa možete tamo direktno pushati
> >>
> >>
> https://github.com/osm-hr/editor-layer-index/tree/gh-pages/sources/europe/hr
> >>
> >> HOK ja rješavam, ali trebaju nam RGI, te svi DOF-ovi da završimo sve DGU
> >> slojeve s aliste: https://github.com/osm-hr/osm-hr/issues/60
> >>
> >>
> >>
> >> ___
> >> Talk-hr mailing list
> >> Talk-hr@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-hr
> >>
> > ___
> > Talk-hr mailing list
> > Talk-hr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-hr
> >
>
>
>
> ___
> Talk-hr mailing list
> Talk-hr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-hr
>


-- 
Darko Boto
Phone: +385 1 6676 918
mob:   +385 91 1365 614
e-mail: darko.b...@gmail.com
___
Talk-hr mailing list
Talk-hr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-hr

Re: [talk-au] Suburban Tunnel at Sydney Central Station

[forster]

How about disused:

https://wiki.openstreetmap.org/wiki/Key:disused:

Tony


On 15/10/19 00:00, Luke Stewart wrote:

G'day,

As of 13/10/19, part of the suburban tunnel at Central station has   
been closed off of public access due to Metro works   
(https://www.openstreetmap.org/#map=19/-33.88344/151.20682). I   
originally changed the access tag from "customers" to "no" on the   
affected segments, but am wondering whether it may be appropriate   
to delete the element all together. My though processes is as there  
 are various other tunnels that are closed but blocked off like  
this  one, it should remain with access=no until such time that we  
can  confirm they are demolished (i.e. when the new walkway opens  
in a  few years).


What do you think? Thanks.


I would go with access=private as workers migt be using the tunnel or
parts of it.

And I'd put the tunnels as a construction so that its existence is less
than completed.
So highway=construction, construction=footway.

I don't know if the name is a real name either .. might be better as a
description?


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

_
This mail has been virus scanned by Australia On Line
see http://www.australiaonline.net.au/mailscanning






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

Re: [Diversity-talk] Your talk submission for SotM 2019

[Rebecca Firth]

Hey everyone,

Thanks to those who took a look already. I am planning to post this on
Wednesday so if you want to input, please do it before then!

Thanks,

Rebecca

On Wed, Oct 9, 2019 at 11:49 AM Rebecca Firth 
wrote:

> Hi All,
>
>
>
> As promised, sharing a draft on the diversity session blog. I think this
> would be best to post as an OSM Diary and submit to WeeklyOSM. I’m also
> coordinating on if it can go on the HOT website. Please add your thoughts
> and ideas by the end of the weekend so we can move forward and post it?
>
>
> https://docs.google.com/document/d/1BjUHky9N71IjMGYCYrwhEUTmu3BZOTNb-WaIxPzqbmY/edit
>
>
> Thanks,
>
>
>
> Rebecca
>
> On Mon, Sep 30, 2019 at 4:41 PM Rebecca Firth 
> wrote:
>
>> Hi there,
>>
>> I took a load of notes, but unfortunately a bit snowed under this week
>> with quite a variety of project deadlines -- is it okay if I add them in by
>> Wednesday?
>>
>> Thanks!
>>
>> On Mon, Sep 30, 2019 at 4:30 PM Heather Leson 
>> wrote:
>>
>>> Dear colleagues, thank you so much for this discussion.
>>>
>>> I started the draft here - https://pads.ccc.de/bwWXryNYXv
>>>
>>> Rebecca, I think you took some notes as well?  would you be able to fold
>>> these in?
>>>
>>> Can we aim to publish on Saturday?
>>>
>>> Heather
>>> Heather Leson
>>> heatherle...@gmail.com
>>> Twitter/skype: HeatherLeson
>>> Blog: textontechs.com
>>>
>>>
>>> On Thu, Sep 26, 2019 at 10:40 PM Miriam Mapanauta 
>>> wrote:
>>>
 Hi to all,

 So great to see you last week, I was very happy to see so many people
 joining and participating in the Panel. Many people is asking me if it was
 recorded because they would love to watch it, I am aware it was not
 recorder but I suggest that we write a blog with the concerns and actions
 we heard we should be taking in the future. I would be glad to co-write
 something in the coming weeks.

 Big hug from sunny Mexico!

 Miriam

 On Tue, Sep 17, 2019 at 2:46 PM Rory McCann 
 wrote:

> Sat. lunchtime or 2nd break is fine with me.
>
> See yous soon! :)
>
> On So, Sep 15, 2019 at 6:20 PM, Heather Leson 
>
> wrote:
> > Dennis, we would love for you to join us. Please add your name to
> the
> > hackpad.
> >
> > All - would it be possible to meet at lunch or second break on
> > saturday to talk through the plan.
> >
> > See you soon
> >
> > Heather
> > Heather Leson
> > heatherle...@gmail.com
> > Twitter/skype: HeatherLeson
> > Blog: textontechs.com
> >
> >
> > On Sun, Sep 15, 2019 at 5:40 PM Dennis Raylin Chen
> >  wrote:
> >> Hi Heather,
> >>
> >> If you need a East Asia perspect,
> >>
> >> Maybe I could help.
> >>
> >> Sorry for the late reply.
> >>
> >> Dennis Raylin Chen
> >>
> >>
> >>
> >> Heather Leson  於 2019年9月13日 週五
> >> 09:17 寫道：
> >>> Hirray. So if folks can add their names to the chart, this will
> >>> help. Maybe we could lunch on saturday to plan.
> >>>
> >>>
> >>> Heather
> >>>
> >>> On Fri, 13 Sep 2019, 07:27 Gertrude Namitala,
> >>>  wrote:
>  Hello Heather,
> 
>  I will help out. Sorry for delay in response.
> 
>  Kind regards,
>  Gertrude
> 
>  On Sun, 8 Sep 2019, 20:07 Heather Leson, 
>
>  wrote:
> > HI folks, I heard back from Rebecca and Patricia. they will help
> > out. We would very much like to engage others. Let me know if
> you
> > would like to be involved.  We will need the following:
> >
> > 4 or 5 helpers (low prep, just help lead a discussion)
> > an OSM Diary. Happy to cowrite with you
> >
> > Our allies at the Mozilla Diversity and Inclusion mailing list
> > suggested a format. I think it is helpful. I put the notes and
> > format draft here. Edits welcome
> >
> > https://pads.ccc.de/bwWXryNYXv
> >
> > See you soon
> >
> > Heather
> >
> > Heather Leson
> > heatherle...@gmail.com
> > Twitter/skype: HeatherLeson
> > Blog: textontechs.com
> >
> >
> > On Tue, Sep 3, 2019 at 6:47 PM Heather Leson
> >  wrote:
> >> Dear colleagues,
> >>
> >> I hope that your summer was grand.
> >>
> >> I am researching formats for this. One thing that might help us
> >> is to tackle what is inclusive language and what are some of
> the
> >> measures to improve diversity - specifically in the board and
> >> working groups. Thoughts?
> >>
> >> "The OSM community is global and diverse. Building on last
> >> year's Open Heroines conversation, we will co-create a space
> for
> >> OSM to talk about how to improve diversity and inclusion in our
> 

Re: [Talk-de] Automatisches Hinzufügen von cash_withdrawal zu Rewe-Supermärkten

[Sebastian Dicke]

Hallo,


deinem ersten Einwand könnte man dadurch entgegenkommen, indem man nur
Supermärkte berücksichtigt, die in letzter Zeit bearbeitet wurden (sagen
wir mal dieses Jahr). Man könnte das noch erweitern, indem man auch
Märkte berücksichtigt, in deren (unmittelbaren) Nähe in letzter Zeit
POIs bearbeitet wurden oder so etwa wie Sitzbänke und Mülleimer
hinzugefügt wurden. Dann stehen die Chancen gut bis sehr gut, dass dort
ein Mapper vor Ort war, dem ein Wegfall oder ein Neubezug des Marktes
hätte auffallen können. Man könnte die Änderungssätze filtern, sodass
die berücksichtigt werden, wo als Quelle survey angegeben wurde und
außerdem reine geometrische Änderungen ausschließen. Damit würden
vermutlich nur wenige Märkte fälschlicherweise mit cash_withdrawal=*
getaggt.

Grüße


Sebastian


Am 14.10.19 um 22:23 schrieb Frederik Ramm:

Hallo,

On 10/14/19 21:47, Michael Brandtner via Talk-de wrote:

Damit wir diesen Tag nicht ??ber Jahre
nach und nach manuell zu den Superm??rkten hinzuf??gen m??ssen, m??chte
ich dies gerne automatisch durchf??hren.

Was aber, wenn irgendwo in OSM ein Rewe getaggt ist, der inzwischen
schon lang ein anderer Supermarkt, oder geschlosse, ist? Dann

1. fügst Du dem fälschlicherweise ein cash_withdrawal hinzu

2. erweckst Du Durch das Editieren des Objekts den Anschein, seine
Existenz zu bestätigen (statt "zuletzt editiert vor 10 Jahren" steht
dann da "zuletzt editiert vor 10 Tagen", und jeder glaubt, dann kann man
sich ja drauf verlassen, dass es den Markt auch wirklich noch gibt)

Das sind meine Standard-Argumente gegen automatisches Editieren.

Im konkreten Fall kommt hinzu, dass Rewe sich das jederzeit anders
überlegen kann. Dann ändert man alles wieder zurück. Die an das einzelne
Objekt *allein* aufgrund von vorhandenem "brand" oder "name" angebrachte
Information "hier kann man Geld abheben" ist redundant.

Bye
Frederik



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

Re: [Talk-de] Automatisches Hinzufügen von cash_withdrawal zu Rewe-Supermärkten

[Michael Brandtner via Talk-de]

Deine letzten beiden Argumente gehen meiner Meinung nach ein bisschen am Thema 
vorbei. Redundanz haben wir ja ständig (jedes brand=McDonald's ist 
amenity=fast_food) und dass Rewe den Service auch wieder abschaffen kann, ist 
auch so, wenn wir den Tag manuell hinzufügen.
Die scheinbare Aktualität ist immer ein Problem bei automatischen Edits, das 
stimmt. Meinst du, es wäre eine mögliche Lösung, nur POIs zu editieren, die 
innerhalb der letzten 6 Monate aktualisiert wurden?
Viele Grüße Michael 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[OSM-talk-ie] theme it is for me then | Re: How to map Irish pubs?

[Rory McCann]

On 09/10/2019 00:14, Mateusz Konieczny wrote:
> 8 Oct 2019, 23:43 by t4d...@gmail.com:
>> This doesn't directly solve the problem, but you could use the
>> brand tag and put in the Guinness and other drinks that are
>> traditionally in an Irish pub if you knew their selection.
>
> I would expect brand tag to be brand of pub (what AFAIK is rare), not
> list of brands of its inventory.

I agree. `brand` is for (e.g.) `brand=Weatherspoons`. You could use
`sells:Guinness=yes` to record that something is sold. But that's not
always helpful, because (e.g.) there are many pubs in England that sell
Guinness and aren't “Irish pubs”, and Irish pubs which don't sell
Guinness (there's one in my city like that, but they will sell you a
“Black & Tan” ).

On 09.10.19 12:08, Martin Koppenhoefer wrote:
> (well, unless you care for/can define the distinction between Irish
> and British pubs)

At a minimum they tend to self identify, having “Irish Pub” in the name.
Or just go in and see if they have green white and orange flags (irish
pub), or big ben, and queen elizabeth pictures (British). (Though
there's a "British" pub in my city with murals of Irish revolutionary
Wolfe Tone on the wall, so 路 )

On 09.10.19 00:20, Graeme Fitzpatrick wrote:
> Bit of an awkward one, but there are pub's in Northern & Inland
> Australia that white people are NOT welcome in (& I'm absolutely
> certain that the same thing, & reverse, applies in many places). Is
> that something that we could / should list against OSM pubs?

“Unwelcoming to $ETHNICY/$RACE” is too subjective for OSM, so doesn't
belong in OSM. Plus with structural racism, you'd almost have to tag
_every_ establishment as “Unfriendly to $MARGINALIZED_GROUP”.

I tried to come up with a clear definition for LGBTQ venues (
https://wiki.openstreetmap.org/wiki/Key:lgbtq ), and I think it's
working, and there aren't many venues which are ambiguous.

On 09.10.19 00:15, Dave Corley wrote:
> My way would be to keep it as simple as possible and as logical 
aspossible>

> in both tagging and structure.> Therefore
>
> amenity = pub
> pub = irish
>
> or potentially even
>
> pub:theme = irish

On 09.10.19 16:39, Richard Fairhurst wrote:
> I asked about cycle cafés a while back (e.g. 
https://www.cafe-ventoux.cc) and

> the consensus was also to use theme

Simple is important. I do like `theme=irish`, being an adjective, rather 
than a
subtag of "pub", potentially allowing other themed things (like themed 
cafe's

here).

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

Re: [talk-au] Suburban Tunnel at Sydney Central Station

[Warin]

On 15/10/19 00:00, Luke Stewart wrote:

G'day,

As of 13/10/19, part of the suburban tunnel at Central station has 
been closed off of public access due to Metro works 
(https://www.openstreetmap.org/#map=19/-33.88344/151.20682). I 
originally changed the access tag from "customers" to "no" on the 
affected segments, but am wondering whether it may be appropriate to 
delete the element all together. My though processes is as there are 
various other tunnels that are closed but blocked off like this one, 
it should remain with access=no until such time that we can confirm 
they are demolished (i.e. when the new walkway opens in a few years).


What do you think? Thanks.


I would go with access=private as workers migt be using the tunnel or 
parts of it.


And I'd put the tunnels as a construction so that its existence is less 
than completed.

So highway=construction, construction=footway.

I don't know if the name is a real name either .. might be better as a 
description?



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

Re: [OSM-legal-talk] conflicting statements in Community Guidelines

[Kathleen Lu via legal-talk]

Recall that under the geocoding guidelines, it is not considered a
substantial extra if "only names, addresses, and/or latitude/longitude
information are included in the Geocoding Results," "the collection is not
a systematic attempt to aggregate all or substantially all Primary Features
of a given type (as defined in the Collective Database Guideline) within a
geographic area city-sized or larger." This is not the same as
"restaurants" since there are additional features that can be included with
a restaurant (though some restaurants will only be name/address/latlong).
(Also, I would not conclude that 4000 restaurants is clearly insubstantial
under database protection law, I think that's an open question. I have not
seen definitive case law as to whether "substantial" is measured by
percentage or absolute number.)
Also "A collection of Geocoding Results will be considered a systematic
attempt to aggregate data if it is used as a general purpose geodatabase,
regardless of how the original aggregation was accomplished." so the
intended usecase of the collection would matter as well.
Recall that you can *always* store together, as mere storage is not a
public use that would trigger any ODbL obligations anyway. What you do with
the data once you put it together *and* how to put it together both impact
potential obligations under ODbL.
It is not a conflict with the Collective Database Guideline or the
Horizontal Map Layers guideline because those describe situations where two
databases are considered Collective Databases regardless of the intended
usecase or the tags involved, whereas the Geocoding Guideline specifics
tags, usecases, and extraction parameters that would not be considered
Substantial.
-Kathleen


On Mon, Oct 14, 2019 at 8:09 AM Lars-Daniel Weber 
wrote:

> Hi again,
>
> sorry for creating another topic, it's somehow related, but somehow
> different.
>
> Community Guideline "Horizontal Map Layers" doesn't allow to cherry-pick
> features within the same layer from a proprietary dataset to complete
> missing data in OSM without triggering share-alike.
>
> Community Guideline "Geocoding" allows cherry-picking as quoted here:
>
> > The OSM-based Geocoding Results are an insubstantial extract or
> > contain no OSM data and thus do not trigger share-alike obligations
> > and can be stored together with the non-OSM-based Geocoding Results
> > with no impact on the non-OSM-based Geocoding results, so long as the
> > aggregated collection of results does not contain the whole or a
> > substantial part of the OSM database. The cloud-based Geocoder is,
> > however, required to credit OpenStreetMap as described in Section 4.3
> > of the ODbL.
>
> Let's say, you're picking 5,000 restaurants, which is clearly a
> insubstantial part of all restaurants in planet file. For 4,000 items,
> you'll get coordinates from the proprietary dataset, for the other 1,000
> items you can pick coordinates from OSM. It won't trigger share alike, it's
> insubstantial and can be stored together.
>
> Isn't that a violation of "Horizontal Map Layers", since it's on the same
> layer?
>
> Confused,
> Lars-Daniel
>
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-de] Automatisches Hinzufügen von cash_withdrawal zu Rewe-Supermärkten

[Frederik Ramm]

Hallo,

On 10/14/19 21:47, Michael Brandtner via Talk-de wrote:
> Damit wir diesen Tag nicht ??ber Jahre
> nach und nach manuell zu den Superm??rkten hinzuf??gen m??ssen, m??chte
> ich dies gerne automatisch durchf??hren.

Was aber, wenn irgendwo in OSM ein Rewe getaggt ist, der inzwischen
schon lang ein anderer Supermarkt, oder geschlosse, ist? Dann

1. fügst Du dem fälschlicherweise ein cash_withdrawal hinzu

2. erweckst Du Durch das Editieren des Objekts den Anschein, seine
Existenz zu bestätigen (statt "zuletzt editiert vor 10 Jahren" steht
dann da "zuletzt editiert vor 10 Tagen", und jeder glaubt, dann kann man
sich ja drauf verlassen, dass es den Markt auch wirklich noch gibt)

Das sind meine Standard-Argumente gegen automatisches Editieren.

Im konkreten Fall kommt hinzu, dass Rewe sich das jederzeit anders
überlegen kann. Dann ändert man alles wieder zurück. Die an das einzelne
Objekt *allein* aufgrund von vorhandenem "brand" oder "name" angebrachte
Information "hier kann man Geld abheben" ist redundant.

Bye
Frederik

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

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

Re: [Talk-us] National Forests and Private Ownership

[Kevin Kenny]

On Mon, Oct 14, 2019 at 3:10 PM Mike Thompson  wrote:
>
> Not all of the land within US National Forests is owned by the US Government, 
> there are private "inholdings" [1].
>
> The boundaries between government land and private land are often marked by 
> signs, e.g.[2]  The above photo is geotagged, and if you drag it into JOSM 
> you can see that it is quite far from the overall National Forest boundary as 
> currently depicted in OSM[3].
>
> The wiki mentions "inholdings", but it is not clear how these should be 
> mapped[4].
>
> How should these be mapped?
> access=private/permissive?
> ownership=private?

New York has a precisely parallel situation, with government-owned,
public-access land that has private inholdings. (Or odd cases where
the inholdings belong to a county or municipality, or to a different
government department.)


At present, I don't specifically map the inholdings - eventually they
probably ought to have mapping for some combination of landuse and
landcover. Instead, I simply have them as inner ways in the
multipolygon that represents the forest (or wilderness area, or park,
or whatever).

https://www.openstreetmap.org/relation/6362588 is a typical complex
case where a forest has both inholdings and exclaves. Many of the Wild
Forest areas in the Adirondack and Catskill Parks are similarly
diffuse.
https://www.openstreetmap.org/relation/6360488 is a large wilderness
area that is considerably more compact, but still has some inholdings,
as well as travel corridors for certain roads.

Of course, if an inholding is also an identifiable feature that
deserves tagging on its own, then it gets tagged.  The Rollins Pond
campground https://www.openstreetmap.org/way/429190169 has an outer
way that is also an inner way of the Saranac Lakes Wild Forest
https://www.openstreetmap.org/relation/6362702

Mappers across the border in Vermont seem to have been approaching the
problem in the same way for National Forests. The Green Mountain
National Forest https://www.openstreetmap.org/relation/1610352 is a
multipolygon that has a great many inner ways, one of which is tagged
separately as the George D. Aiken Wilderness
https://www.openstreetmap.org/way/116060605.  (This is a case where
I'm not positive that the mapping is right; I thought that the Aiken
Wilderness was part of the GMNF, but the topology seems to indicate
that it exists independently. Not my turf; I'll let the locals deal
with it.)

This practice can handle cases of almost unlimited weirdness, sich as
a National Park corridor that partly traverses a State Park, but is
itself broken up by rights-of-way for roads and power lines.
https://www.openstreetmap.org/relation/6523267

By the way, I also make cutouts if I know that a right-of-way is NOT
part of the feature being mapped.  Woodland Valley Road,
https://www.openstreetmap.org/way/20213204, although it exists as an
easement for the inholding to the west, is part of the campground, and
it's obvious when you're driving it that you're "in" the campground.
By contrast, Red Hill Road where it runs through the Dinch Road unit
https://www.openstreetmap.org/relation/6304739 remains the property of
the Department of Transportation, not the Bureau of Water Supply, and
there's a distinct sense that you're leaving and re-entering the
forest unit when you cross the road. Stewart State Forest
https://www.openstreetmap.org/relation/6367564 is cut away for the
rights-of-way of the power line and the state and county roads, but
not for the logging roads or the residential access easement to the
east.

This tagging practice is controversial, and many mappers feel that I
should conjoin the regions if the forest unit exists on both sides of
the highway. I'm following the practice of the managing agencies.

(Ignore the alignment problems on the highways in these examples for
now. The cadastre in this part of the world is ... approximate. I'm
doing what I can with the data I've got.)

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

[Talk-de] Automatisches Hinzufügen von cash_withdrawal zu Rewe-Supermärkten

[Michael Brandtner via Talk-de]

Hallo,

ich m??chte gerne meinen ersten automatischen Edit ausf??hren und daf??r 
mit euch R??cksprache halten. Diesen Beitrag habe ich parallel auch im 
Forum gepostet.


Der vor kurzem offiziell akzeptierte Tag cash_withdrawal[1] gibt an, ob 
es die M??glichkeit gibt, in einem Gesch??ft Geld abzuheben. Dies ist in 
allen Rewe-Superm??rkten in Deutschland der Fall. Dies steht nicht nur 
auf der Website des Konzerns[2], es wurde mir auch im E-Mail-Kontakt mit 
dem Kundenservice best??tigt. Damit wir diesen Tag nicht ??ber Jahre nach 
und nach manuell zu den Superm??rkten hinzuf??gen m??ssen, m??chte ich dies 
gerne automatisch durchf??hren. Weitere Details sind auf der von mir 
hierf??r angelegten Seite im Wiki zu finden.[3]


Ich bin gespannt auf euer Feedback.

Viele Gre
Michael


[1] https://wiki.openstreetmap.org/wiki/Key:cash_withdrawal
[2] https://www.rewe.de/service/bargeld-abheben/
[3] https://wiki.openstreetmap.org/wiki/Automated_edits/Discostu36


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

[Talk-us] National Forests and Private Ownership

[Mike Thompson]

Not all of the land within US National Forests is owned by the US
Government, there are private "inholdings" [1].

The boundaries between government land and private land are often marked by
signs, e.g.[2]  The above photo is geotagged, and if you drag it into JOSM
you can see that it is quite far from the overall National Forest boundary
as currently depicted in OSM[3].

The wiki mentions "inholdings", but it is not clear how these should be
mapped[4].

How should these be mapped?
access=private/permissive?
ownership=private?

Mike
[1] https://en.m.wikipedia.org/wiki/Inholding
[2]https://photos.app.goo.gl/fQustnLzNzSSjiSK8
[3] https://www.openstreetmap.org/relation/395767
[4] https://wiki.openstreetmap.org/wiki/US_Forest_Service_Data
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset

[Kathleen Lu via legal-talk]

The reference to countries come from the Regional Cuts Guideline (and then
the later Collective Database Guideline), in case that was not clear.
I don't see how roads and houses (do you mean building footprints?) would
be "mixture on the same layer" or why the layer matters since they're
different data types...

On Mon, Oct 14, 2019 at 8:33 AM Lars-Daniel Weber 
wrote:

> From: "Kathleen Lu via legal-talk" 
> > Lars-Daniel already said that they are kept in separate columns and not
> > de-duplicated. There is no requirement that, in order to function as a
> > Collective Database, data types may not be used together to create a
> > Produced Work. To the contrary, the guidance is that the most axiomatic
> > Produced Work, a global map, may be created from multiple Collective
> > Databases consisting of different data types and/or different countries.
>
> Hmm... but doesn't this violate "Horizontal Layers" Guideline?
>
> Let's say you're creating a map of Western, taking roads from OSM in
> Germany and houses from proprietary data from all other countries, since
> OSM is incomplete here. Isn't this a mixture on the same layer?
>
> I think, there's no difference in this guideline between small and large
> scale.
>
>
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-br] React Native com Openstreetmap

[Vitor George]

Oi Fabrício,

Recomendo dar uma olhada no módulo abaixo, ele oferece mais opções de
customização de mapas:

https://github.com/react-native-mapbox-gl/maps

Ele é usado no editor Observe, que tem o OSM como mapa base. Link pro
repositório:

https://github.com/developmentseed/observe

Abraços,
Vitor


On Mon, Oct 14, 2019 at 5:27 PM Fabricio Calvete Campos <
fabricio_calv...@hotmail.com> wrote:

> Bom dia a todos, estamos com uma equipe de 5 profissionais trabalhando com
> react-native para implantar no Openstreetmap em uma solução de rotas e não
> estamos conseguindo ao mais básico que é localização de nossos aplicativos,
> chegamos a um senso comum que existe alguma configuração que não deixa o
> openstreetmap interagir com react maps, alguém já passou por isto ou tem
> alguma dica?
>
> Fabricio Calvete Campos
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [OSM-talk-fr] Tour antigel

[osm . sanspourriel]

Ce qui me dérange dans wind machine
, c'est que le sens usuel
est la machine à imiter le bruit du vent dans les opéras (éoliphone) et
que c'est bien générique. Une éolienne c'est aussi une machine à vent.

La page de désambigüisation de Wikipedia EN ne propose même pas ce sens.

Ce n'est qu'en connaissant le contexte qu'on peut comprendre (quand on
cite la FAO, on comprend qu'il s'agit d'agriculture ou de nourriture).

Wind machine a l'inconvénient inverse d'antifreeze tower: l'un dit
comment mais pas quoi, l'autre c'est le contraire.

antifreeze_wind_machine serait non ambigu. Long et pas génial je l'accorde.

Fan (ventilateur) est plus explicite que wind machine et est aussi
utilisé par la FAO :

Most wind machines (or fans) blow air almost horizontally to mix warmer
air aloft in a temperature inversion with cooler air near the surface.


Two_blade_fan si on veut être explicite.

Un attribut important c'est height à cause des drones et Cie.

D'autres idées ?

Jean-Yvon

Le 14/10/2019 à 15:39, ades - ades.s...@orange.fr a écrit :

‘wind_machine' avec renvoi sur le site de la fao, et si le tag plait,
à noter dans le wiki…
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-br] React Native com Openstreetmap

[Fabricio Calvete Campos]

Bom dia a todos, estamos com uma equipe de 5 profissionais trabalhando com 
react-native para implantar no Openstreetmap em uma solução de rotas e não 
estamos conseguindo ao mais básico que é localização de nossos aplicativos, 
chegamos a um senso comum que existe alguma configuração que não deixa o 
openstreetmap interagir com react maps, alguém já passou por isto ou tem alguma 
dica?

Fabricio Calvete Campos
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-es] Importaciones Catastro

[Jorge Sanz Sanfructuoso]

Tiene que ser algo del CSV que guarda y no soporta como comentas. Pasa el
CSV a ver si vemos que puede suceder.

Saludos.

El lun., 14 oct. 2019 a las 17:44, Joaquim () escribió:

> Hola,
>
>  Estoy preparando la importación de Alaior, en Menorca (07002) y,
> una vez revisados los nombres de las calles intento hacer la segunda
> pasada del programa catatom2osm y se aborta por un error: Error al
> cargar el archivo CSV '07002/highway_names.csv'
>
>  Si lo hago sin modificar el archivo highway_names.csv la segunda
> vuelta se realiza sin problemas. Para editar el csv he usado la hoja de
> cálculo de LibreOffice como en anteriores ocasiones (otros municipios)
> en las que no tuve problemas. La versión de catatom2osm es la 1.2dev (la
> misma que en otras ocasiones).
>
>  Supongo que al abrir y guardar el programa csv se produce algún
> cambio que no soporta el programa de importación.
>
>  ¿Alguien puede ayudarme a solucionarlo?
>
> Muchas gracias
>
> Joaquim
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>


-- 
Jorge Sanz Sanfructuoso - Sanchi
Blog http://jorgesanzs.es/
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[Talk-es] Importaciones Catastro

[Joaquim]

Hola,

    Estoy preparando la importación de Alaior, en Menorca (07002) y, 
una vez revisados los nombres de las calles intento hacer la segunda 
pasada del programa catatom2osm y se aborta por un error: Error al 
cargar el archivo CSV '07002/highway_names.csv'


    Si lo hago sin modificar el archivo highway_names.csv la segunda 
vuelta se realiza sin problemas. Para editar el csv he usado la hoja de 
cálculo de LibreOffice como en anteriores ocasiones (otros municipios) 
en las que no tuve problemas. La versión de catatom2osm es la 1.2dev (la 
misma que en otras ocasiones).


    Supongo que al abrir y guardar el programa csv se produce algún 
cambio que no soporta el programa de importación.


    ¿Alguien puede ayudarme a solucionarlo?

Muchas gracias

Joaquim


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

Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset

[Lars-Daniel Weber]

From: "Kathleen Lu via legal-talk" 
> Lars-Daniel already said that they are kept in separate columns and not
> de-duplicated. There is no requirement that, in order to function as a
> Collective Database, data types may not be used together to create a
> Produced Work. To the contrary, the guidance is that the most axiomatic
> Produced Work, a global map, may be created from multiple Collective
> Databases consisting of different data types and/or different countries.

Hmm... but doesn't this violate "Horizontal Layers" Guideline?

Let's say you're creating a map of Western, taking roads from OSM in Germany 
and houses from proprietary data from all other countries, since OSM is 
incomplete here. Isn't this a mixture on the same layer?

I think, there's no difference in this guideline between small and large scale.




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

[OSM-legal-talk] conflicting statements in Community Guidelines

[Lars-Daniel Weber]

Hi again,

sorry for creating another topic, it's somehow related, but somehow different.

Community Guideline "Horizontal Map Layers" doesn't allow to cherry-pick 
features within the same layer from a proprietary dataset to complete missing 
data in OSM without triggering share-alike.

Community Guideline "Geocoding" allows cherry-picking as quoted here:

> The OSM-based Geocoding Results are an insubstantial extract or
> contain no OSM data and thus do not trigger share-alike obligations
> and can be stored together with the non-OSM-based Geocoding Results
> with no impact on the non-OSM-based Geocoding results, so long as the
> aggregated collection of results does not contain the whole or a
> substantial part of the OSM database. The cloud-based Geocoder is,
> however, required to credit OpenStreetMap as described in Section 4.3
> of the ODbL.

Let's say, you're picking 5,000 restaurants, which is clearly a insubstantial 
part of all restaurants in planet file. For 4,000 items, you'll get coordinates 
from the proprietary dataset, for the other 1,000 items you can pick 
coordinates from OSM. It won't trigger share alike, it's insubstantial and can 
be stored together.

Isn't that a violation of "Horizontal Map Layers", since it's on the same layer?

Confused,
Lars-Daniel



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

Re: [OSM-legal-talk] map drawn based on OSM tiles

[Lars-Daniel Weber]

According to community guideline for "Geocoding", I'm not using original OSM data in my new map at all. Since I've drawn lines from paper drawn on an Produced Work of OSM data, I don't have any of the original OSM elements in my final dataset, which are in the OSM dataset.

 

So, I just need to credit OpenStreetMap as decribed in Section 4.3 of the ODbL, since it's a Produced Work.

 

 

> Users of a navigation application send an address search query to a
> cloud-based Geocoder. The Geocoder has access to two separate map
> databases, one of which contains solely OSM data. The other database
> contains non-OSM data. If the address is accurately found in the OSM
> database, the location is sent back to the navigation application. If
> the address is not found in the OSM database, then the other database is
> searched, and that result is returned. (The same example applies when
> the third party database is searched before the OSM database or when
> they are searched concurrently.) The OSM-based Geocoding Results are an
> insubstantial extract or contain no OSM data and thus do not trigger
> share-alike obligations and can be stored together with the
> non-OSM-based Geocoding Results with no impact on the non-OSM-based
> Geocoding results, so long as the aggregated collection of results does
> not contain the whole or a substantial part of the OSM database. The
> cloud-based Geocoder is, however, required to credit OpenStreetMap as
> described in Section 4.3 of the ODbL.

 

Gesendet: Montag, 07. Oktober 2019 um 20:05 Uhr
Von: "Kathleen Lu" 
An: "Licensing and other legal discussions." 
Cc: "Lars-Daniel Weber" 
Betreff: Re: [OSM-legal-talk] map drawn based on OSM tiles


> Thus, assuming the shapefiles are essentially the equivalent of

> simplified OSM border shapefiles, the shapefiles are covered by ODbL.

Actually, it's like 40% OSM borders (hard borders, like roads, rivers, topography and administrative stuff) and 60% own borders, which don't appear in OSM. BUt those borders wouldn't make OSM any better, since they're specific for the current task.
 

My view would be the OSM borders are ODbL. Just because it's one shapefile doesn't mean all of the data in the shapefile has to be under one license. If the other borders are not border types that are in OSM that you have traced, ODbL does not implicate them per the Collective Database Guideline.

 

> Now, it sounds like you're not tracing very much, so it's possible that
> you have traced fewer than 100 features in which case your tracing is
> insubstantial
> https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline

Actually, I've traced more than 100 features, but the "extraction is non-systematic and clearly based on your own qualitative criteria" - okay, not on my one, but on the one who draw the overlay with the pen.
 
It's possible that your extraction is insubstantial, though I can't say definitively. But I don't think that you need a definitive answer on whether it's insubstantial, since if your usecase is as a filter to select POIs, then you can do that whether the borders make up a substantial extract or not, and you are willing to provide attribution anyway, so you do not need to conclusively avoid ODbL.






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

Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset

[Lars-Daniel Weber]

I totally have to agree with this.

 



Gesendet: Donnerstag, 10. Oktober 2019 um 23:24 Uhr
Von: "Kathleen Lu via legal-talk" 
An: "Licensing and other legal discussions." 
Cc: "Kathleen Lu" 
Betreff: Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset



 
 

> Extracting than 100 elements (non repeatable) from the databse accounts
> for substantial.

 

The licence doesn't say this at all.


The ODbL defines substantial as:

“Substantial” – Means substantial in terms of quantity or quality or a
combination of both. The repeated and systematic Extraction or
Re-utilisation of insubstantial parts of the Contents may amount to the
Extraction or Re-utilisation of a Substantial part of the Contents.


The interpretation that OSMF has put forward is that it is NOT substantial if an extraction has:
 -   Less than 100 Features.

 - More that 100 Features only if the extraction is non-systematic and clearly based on your own qualitative criteria for example an extract of all the the locations of restaurants you have visited for a personal map to share with friends or use the locations of a selection of historic buildings as an adjunct in a book you are writing, we would regard that as non Substantial. The systematic extraction of all eating places within an area or at all castles within an area would be considered to be systematic.
 - The features relating to an area of up to 1,000 inhabitants which can be a small densely populated area such as a European village or can be a large sparsely-populated area for example a section of the Australian bush with few Features.

 

This does NOT mean than if your extraction ticks up to 101 features, it's definitively substantial (this wouldn't make any sense under copyright law either). Rather it means that it's out of the scope of what the OSMF has given its view on.

 

Cost is a relevant factor in database protection law, which is one of the rights covered by the licence. First, a database is not protected unless there has been "substantial investment" in its making. Second, while users are prohibited from extracting substantial parts of the database without permission (aka a licence), users are affirmatively allowed by the law to extract insubstantial parts (and the database owner actually cannot prevent it). The precise amount that is considered "substantial" is not defined. Rather "A lawful user of a database which is made available to the public in whatever manner may not perform acts which conflict with normal exploitation of the database or unreasonably prejudice the legitimate interests of the maker of the database." Considerations of cost would be a factor for a court to consider in determining this.

 

As for copyright law, I disagree with Tom's statement that "Copyright law does come into effect much earlier than database protection." Copyright law typically protects 1) the contents of a database *if* they are individually copyrightable, a difficult proposition with geodata, and 2) the arrangement and selection of a database, particularly creative choices. It would appear entirely possible, especially when we're dealing with a database of facts, for an extraction to be substantial but copy nothing copyrightable. Imagine, for example, the *random* extraction of 25% of the contents of a database.

 

All that said, I am still of the opinion that it is not necessary to find the exact line here, because the original use Lars-Daniel proposed was one of a collective database so long as the two sets of ZIP properties were kept in separate columns, which he appeared quite comfortable with.

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




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

Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset

[Lars-Daniel Weber]

> Extracting than 100 elements (non repeatable) from the databse accounts for 
>substantial.

That's not correct. I can extract as many as I want. It's just not allowed that 
thew newly created database contains a substantial part of the OSM database.

When I create 100 databases containing 100 features each, it's different to 1 
database containing 10,000 features. The first case isn't substatial, the 
second one might be.

> Costs has nothing to do with the license.

That's not correct. The database directive is all about protecting the 
investment, the database creator has invested into creating the database - no 
matter, what he has invested in creating the data, since this is covered by 
copyright of the elements in the database.

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

Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset

[Lars-Daniel Weber]

From: "Martin Koppenhoefer" 
> "substantial investment" is not the same as monetary cost. The human time 
> that is 
> needed to collect and arrange the data is also an investment.

Creating the items is *not* covered by the database directive. The amount of 
time needed to collect them actually is. The creation is protected by the the 
database content's license or the normal copyright.
 
> are kept in separate columns and are not used in combination/both to create a 
> produced work?

Yes and yes.

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

Re: [OSM-talk-fr] Tour antigel

[ades]

‘wind_machine' avec renvoi sur le site de la fao, et si le tag plait, à noter 
dans le wiki…

> Le 14 oct. 2019 à 11:39, Yves P.  a écrit :
> 
> Bonjour,
> 
> Comment cartographier une tour antigel, machine à vent, wind machine ?
> 
> Ces tours sont érigées dans les vergers, vignes…
> De loin, ça peut ressembler à une éolienne à 2 pales…
> 
> Une seule photo (de son pied) 
> 
>  dans wikimedia commons, rien dans OSM.
> 
> J’en ai trouvé qu'une seule dans taginfo (node 3958519692 
> ), mais la vue routière 
> correspond à une petite éolienne au sommet d’une perche.
> man_made=tower
> tower:type=wind_generator
> 
> tower:type=wind_machine ?
> tower:type=antifreeze ?
> tower:type=antifrost ?
> 
> https://www.tour-antigel.com 
> 
> Pour info, j’ai utilisé wind_machine pour le moment : noeuds 6877573656 
> , 6877573657 
> 
> 
> —
> Yves
> 
> PS: c’est décrit par la FAO : http://www.fao.org/3/y7223e/y7223e0d.htm 
> 
> 
> 
> 
> 
> ___
> 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-fr] Sur 01net L’incroyable histoire de Waze, la carte routière la plus précise au monde... conçue par des bénévoles

[ades]

O1 net c’est quoi ? connais pas… enfin presque, site de m… qui vit sur la pub, 
le fait d’en causer sur le talk va sans doute (certainement)) leur apporter 
plein de lecteurs, donc plus de revenus pub… 
OSM devrait donc leur demander un % pour ces lecteurs supplémentaires, pour une 
fois que 01.m… servirait à quelque chose …
Sinon, si le but est d’être reconnu par des gougnafiers, faut juste leur 
demander combien ils veulent pour causer d’OSM à la place de waze, mais bon,  
j’ai pas envie de payer…

> Le 14 oct. 2019 à 10:55, Vincent Bergeot  a écrit :
> 
> Le 06/10/2019 à 10:45, PierreV a écrit :
>> https://www.01net.com/actualites/l-incroyable-histoire-de-waze-la-carte-routiere-la-plus-precise-au-monde-concue-par-des-benevoles-1777628.html
>> 
>> On contacte 01net pour leur proposer un article sur OSM qui est encore plus
>> "génial" que Waze car réutilisable par n'importe qui?
> 
> 
> il y a quelque temps, alors que l'on parlait de Waze comme le nouveau 
> Wikipédia de la cartographie (!!!), nous avions commencé cela : 
> https://mypads.framapad.org/mypads/?/mypads/group/osm-fr-upup77pw/pad/view/waze-n-est-pas-le-wikipedia-de-la-carto-k91j0b7c5
> 
> peut-être que nous pourrions continuer le texte pour rappeler qu'il y a 
> quelques différences assez fondamentales !
> 
> à plus
> 
> -- 
> Vincent Bergeot
> 
> 
> ___
> 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: [Talk-de] Kreuz Werl - seltsame Spurnutzung

[Florian Lohoff]

On Sun, Oct 13, 2019 at 10:24:33AM +0200, michael spreng wrote:
> Ich interpretiere das leicht anders. routing.openstreetmap.de braucht
> einen anderen Regelsatz:
> https://github.com/fossgis-routing-server/cbf-routing-profiles
> 
> Die auf/abfahrt ist mit maxspeed=none gemappt, welches in 140kmh
> übersetzt wird.
> maxspeed=signals hingegen ist dem Profil unbekannt, und es wird der
> weltweite default für motorway von 90kmh angenommen.
> 
> Wäre es nicht sinnvoll, die auf/abfahrten mit demselben maxspeed zu
> tagen wie die parallele Autobahn?
> 
> Was für eine Geschwindigkeit sollte vom routing bei signals angenommen
> werden?

Das werden wir dem "router" schon sagen müssen. Eine allgemeingültige
Antwort gibts da ja nicht.

Die Frage ist ist da tagsüber nichts und zur Rushhour 100? Oder ist
das zwischen 100 und 130?

Vermutlich macht es Sinn das mit maxspeed:signals= zu taggen. Dann 
hat ein Automat die Chance das rauszufinden.

Ich stelle da aber mal eine ketzerische Frage. Woher kommt
das maxspeed=none auf der Parallelfahrbahn?

Vor dem Abzweig gilt ein maxspeed=signals - Wenn die abzweigt gilt
das weiter - Das ist ja nicht mit einem mal aufgehoben. Man könnte
Argumentieren das das für die neu auf die Autobahn einbiegenden gilt
aber wir betrachten hier den fall der durchfahrenden.

Daher plädiere ich dafür die Parallelfahrbahn ebenfalls auf
maxspeed=signals zu taggen bzw das maxspeed=none _mindestens_ zu 
entfernen es sei denn am Begin der Parallelfahrbahn steht ein Schild
das die bestehende Geschwindigkeitsbegrenzung aufhebt.

Merke: Eine Geschwindigkeitsbegrenzung gilt bis sie aufgehoben wird (Und
eine Einmündung hebt sie nicht auf)

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

[talk-au] Suburban Tunnel at Sydney Central Station

[Luke Stewart]

G'day,

As of 13/10/19, part of the suburban tunnel at Central station has been
closed off of public access due to Metro works (
https://www.openstreetmap.org/#map=19/-33.88344/151.20682). I originally
changed the access tag from "customers" to "no" on the affected segments,
but am wondering whether it may be appropriate to delete the element all
together. My though processes is as there are various other tunnels that
are closed but blocked off like this one, it should remain with access=no
until such time that we can confirm they are demolished (i.e. when the new
walkway opens in a few years).

What do you think? Thanks.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-it] Ospedali, ambulance_station e altro

[Fra Mauro]

C'è consenso sul mappare l'azienda ospedaliera in operator? Io pensavo ad una 
relazione, ma probabilmente è migliore quest'altra soluzione. Se c'è consenso 
mi pare un bel passo in avanti.

Sui pronto scoccorsi: mi pare di ricordare che esista un dataset pubblico con 
la lista dei DEA di primo e secondo livello (DEA = dipartimento emergenza 
accettazione = "pronto soccorso"). Quando posso cerco...

Un saluto

Il 14 Ottobre 2019 14:10:06 CEST, Marcello  ha scritto:
>Il 14/10/19 12:03, Fra Mauro ha scritto:
>> Credo che la situazione sia la stessa di quando si parla della 
>> superficie dei sentieri escursionistici...
>>
>> Io lancio due domande sul tagging e faccio una proposta. Mi sforzerò 
>> di essere pratico! :)
>>
>> 1) vogliamo mappare l'Azienda Ospedaliero Universitaria Pisana ( 
>> http://www.ao-pisa.toscana.it/) o l'Ospedale di Cisanello 
>> (https://www.openstreetmap.org/relation/9243476)? Il secondo è quello
>
>> che la persona normale chiama appunto ospedale, la prima è la 
>> struttura amministrativa che include l'ospedale e che interessa alla 
>> P.A. di cui parlava AleZena. Tenete presente che una azienda 
>> ospedaliera può includere più ospedali, a volte divisi anche da 
>> qualche km. Inoltre può succedere che l'informazione interessi anche 
>> al normale cittadino. La lista delle Aziende Ospedaliere è più 
>> semplice da reperire. Ovviamente la situazione ottimale sarebbe 
>> mappare entrambe le cose.
>Direi che se l'azienda ospedaliera include più ospedali sicuramente 
>questi sono identificati con nomi diversi, quindi ognuno si mappa come 
>singolo ospedale e si mette in operator il nome dell'azienda
>ospedaliera
>>
>> 2) vogliamo distinguere l'ospedale dalla clinica? In base al tagging 
>> sono tutti e due amenity=hospital...
>prendendo spunto dalla sollecitazione di Alessandro ho fatto una 
>verifica della mappatura in Umbria, ho trovato qualche poliambulatorio 
>delle aziende sanitarie pubbliche etichettato come amenity=hospital, 
>cambiato in amenity=clinic, mentre le cliniche private presenti 
>(qualcuna non c'è ancora) erano sempre etichettate con amenity=clinic, 
>mentre come dice la pagina wiki (aggiornata a febbraio scorso dopo
>altro 
>thread qui) è più corretto amenity=hospital, quelle che ho modificato 
>hanno tutte posti letto per degenze ordinarie, sale operatorie, diverse
>
>specializzazioni, quello che le differenzia dagli ospedali pubblici è
>la 
>presenza del pronto soccorso, quindi se non era presente (mi sembra ci 
>fosse su tutte ma non sono sicuro) ho aggiunto emergency=no, quindi ho 
>aggiunto in "operator" la società proprietaria e operator:type=private,
>
>mentre tutte le strutture appartenenti al servizio pubblico le ho 
>etichettate con operator:type=public. Secondo me è un modo semplice ed 
>efficace per distinguere la sanità pubblica da quella privata.
>
>-- 
>Ciao
>Marcello
>
>
>___
>Talk-it mailing list
>Talk-it@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-it

-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Ospedali, ambulance_station e altro

[Marcello]

Il 14/10/19 12:02, Lorenzo Pesci ha scritto:

Nella mia zona ho trovato sospetto
questo inserimento:
6 ospedali mappati e nessuna corrispondenza sul web

Come quello segnalato da A.Palmas, anche questo è dell'utente mcheck .
https://www.openstreetmap.org/way/712913302#map=18/43.18101/11.98406

Non ne so abbastanza però per andare a modificare con sicurezza
(a parte riunire 6  [amenity hospital] in una unica area). L.Pesci


Lorenzo, quelli sono proprio fuori dall'Umbria quindi non sono entrati 
nella mia estrazione. In quella zona c'è un grosso centro privato ma è a 
qualche km di distanza, peraltro non inserito in mappa, non vorrei che 
mcheck abbia trovato informazioni su quel centro ma con una 
localizzazione non precisa. Purtroppo non ha messo alcuna informazione 
aggiuntiva ad amenity=hospital, come abbia fatto ad etichettare in quel 
modo quegli edifici, mettendo anche l'altezza al centimetro, dal source 
che dichiara (Esri World Imagery (Clarity) Beta) non riesco proprio a 
capirlo.


--

Ciao
Marcello

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

Re: [Talk-it] Ospedali, ambulance_station e altro

[Marcello]

Il 14/10/19 12:03, Fra Mauro ha scritto:
Credo che la situazione sia la stessa di quando si parla della 
superficie dei sentieri escursionistici...


Io lancio due domande sul tagging e faccio una proposta. Mi sforzerò 
di essere pratico! :)


1) vogliamo mappare l'Azienda Ospedaliero Universitaria Pisana ( 
http://www.ao-pisa.toscana.it/) o l'Ospedale di Cisanello 
(https://www.openstreetmap.org/relation/9243476)? Il secondo è quello 
che la persona normale chiama appunto ospedale, la prima è la 
struttura amministrativa che include l'ospedale e che interessa alla 
P.A. di cui parlava AleZena. Tenete presente che una azienda 
ospedaliera può includere più ospedali, a volte divisi anche da 
qualche km. Inoltre può succedere che l'informazione interessi anche 
al normale cittadino. La lista delle Aziende Ospedaliere è più 
semplice da reperire. Ovviamente la situazione ottimale sarebbe 
mappare entrambe le cose.
Direi che se l'azienda ospedaliera include più ospedali sicuramente 
questi sono identificati con nomi diversi, quindi ognuno si mappa come 
singolo ospedale e si mette in operator il nome dell'azienda ospedaliera


2) vogliamo distinguere l'ospedale dalla clinica? In base al tagging 
sono tutti e due amenity=hospital...
prendendo spunto dalla sollecitazione di Alessandro ho fatto una 
verifica della mappatura in Umbria, ho trovato qualche poliambulatorio 
delle aziende sanitarie pubbliche etichettato come amenity=hospital, 
cambiato in amenity=clinic, mentre le cliniche private presenti 
(qualcuna non c'è ancora) erano sempre etichettate con amenity=clinic, 
mentre come dice la pagina wiki (aggiornata a febbraio scorso dopo altro 
thread qui) è più corretto amenity=hospital, quelle che ho modificato 
hanno tutte posti letto per degenze ordinarie, sale operatorie, diverse 
specializzazioni, quello che le differenzia dagli ospedali pubblici è la 
presenza del pronto soccorso, quindi se non era presente (mi sembra ci 
fosse su tutte ma non sono sicuro) ho aggiunto emergency=no, quindi ho 
aggiunto in "operator" la società proprietaria e operator:type=private, 
mentre tutte le strutture appartenenti al servizio pubblico le ho 
etichettate con operator:type=public. Secondo me è un modo semplice ed 
efficace per distinguere la sanità pubblica da quella privata.


--
Ciao
Marcello


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

Re: [Talk-hr] Pomoc oko oznacavanja zona pokrivenosti

[hbogner]

DGU HOK, US topo, Orbview su gotovi. DGU DOF i DGU RGI su preostali.

DOF je hitniji od RGI, ali svaka pomoć je dobrodošla. :)


On 14. 10. 2019. 13:01, Janko Mihelić wrote:

Evo ja ću probati srediti RGI

pon, 14. lis 2019. u 10:23 hbogner  napisao je:


Treba mi pomoć oko označavanja zona pokrivenosti DGU podlogama

Na osm-hr blogu su dva članka sa linkovima na wms servise DGU-a

-

https://osm-hr.org/2019/06/04/pravo-koristenja-mreznih-usluga-prostornih-podataka-drzavne-geodetske-uprave/
-

https://osm-hr.org/2019/07/11/objavljen-digitalni-ortofoto-drzavne-geodetske-uprave-2018/

Trebaju nam poligoni koji označavaju pokrivenost određenim podlogama kao
na

https://github.com/osmlab/editor-layer-index/tree/gh-pages/sources/europe/hr

Projekt je privremeno forkan u osm-hr pa možete tamo direktno pushati

https://github.com/osm-hr/editor-layer-index/tree/gh-pages/sources/europe/hr

HOK ja rješavam, ali trebaju nam RGI, te svi DOF-ovi da završimo sve DGU
slojeve s aliste: https://github.com/osm-hr/osm-hr/issues/60



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


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





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

Re: [Talk-hr] Pomoc oko oznacavanja zona pokrivenosti

[Janko Mihelić]

Evo ja ću probati srediti RGI

pon, 14. lis 2019. u 10:23 hbogner  napisao je:

> Treba mi pomoć oko označavanja zona pokrivenosti DGU podlogama
>
> Na osm-hr blogu su dva članka sa linkovima na wms servise DGU-a
>
> -
>
> https://osm-hr.org/2019/06/04/pravo-koristenja-mreznih-usluga-prostornih-podataka-drzavne-geodetske-uprave/
> -
>
> https://osm-hr.org/2019/07/11/objavljen-digitalni-ortofoto-drzavne-geodetske-uprave-2018/
>
> Trebaju nam poligoni koji označavaju pokrivenost određenim podlogama kao
> na
>
> https://github.com/osmlab/editor-layer-index/tree/gh-pages/sources/europe/hr
>
> Projekt je privremeno forkan u osm-hr pa možete tamo direktno pushati
>
> https://github.com/osm-hr/editor-layer-index/tree/gh-pages/sources/europe/hr
>
> HOK ja rješavam, ali trebaju nam RGI, te svi DOF-ovi da završimo sve DGU
> slojeve s aliste: https://github.com/osm-hr/osm-hr/issues/60
>
>
>
> ___
> Talk-hr mailing list
> Talk-hr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-hr
>
___
Talk-hr mailing list
Talk-hr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-hr

[OSM-talk] "GeoForAll contributions to the United Nations Sustainable Development Goals" webinar recording available

[Suchith Anand via talk]

 

The "GeoForAll contributions to the United Nations Sustainable Development 
Goals" webinar  recording link at https://youtu.be/Bd8Oe1Z-p3E





Thank you Victoria, Rafael and Charlie.





The presentation from Sergio Y Lara (Uruguay) on gvSIG Batovi is an excellent 
example of a successful initiative in Open Principles in Education and helps us 
to understand why scalability and costs for scaling is fundamental . Through 
their focus on Open Principles in Education they have now provided high quality 
spatial education to students in all schools across Uruguay . Thanks to the 
Plan Ceibal they also have free laptops for all Primary and Secondary students 
in the country so they truly have the opportunity to reach every student with 
high quality teaching and learning tools.




https://www.youtube.com/watch?v=orwN9K07XPo
    (Video with English translation)




The presentation from Victor Sunday (Unique Mappers Team) shares the work on 
youth and women empowerment that they are doing in Africa . Their contributions 
to quality education, climate action is inspiring. GeoForAll is working closely 
with YouthMappers and other partners worldwide to help provide geoeducation 
opportunities for all students.




The presentation from Cameron Green (University of Pretoria, South Africa) 
highlighted the importance of Spatial Data Infrastructures (SDI) and the 
fundamental link of SDI to all 17 UN SDGs. Many developing countries lack 
Spatial Data infrastructures which is key for evaluating and monitoring SDG 
progress. He showed GeoNode http://geonode.org    an open source Content 
Management System for GIS. There are many examples of Geonode implementations 
for example the World Food Programhttps://geonode.wfp.org that might be of 
wider interest.



I want to thank all speakers for sharing their experiences and ideas.




As our next step, we to want learn from successful initiatives like gvSIG 
Batovi, GIS at School etc to scale our teacher training programs for schools to 
provide geoeducation and STEM education opportunities to millions of students 
globally and welcome ideas. Spatial Education is key for tackling Climate 
Change. One of our GeoForAll labs established atthe UNEP/GRID-Warsaw Centre in 
Poland has been doing pioneering work on Environmental Management , Active 
Education over many years. Details athttps://www.gridw.pl/en/opensourcegeolab


One of the inspiring work that they are involved is theGIS at School 
http://www.edugis.pl/en/images/stories/guide/gis-at-school.pdf








btw it is nearly 25 years  (in 1994)  since I first came across the amazing 
“geo world” by pure chance. I was able to learn GIS thanks to the help from 
many kind people who I will always be grateful for their kindness to me.   So 
it is now my duty to help open the doors of geoeducation and geodigital economy 
opportunities to everyone. Details at 
https://www.rd-alliance.org/group/geospatial-ig/post/please-share-open-principles-science-and-education-ideas-and-philosophy





I am grateful to everyone working to make geoeducation and digital economy 
opportunities available for everyone.




Best wishes,






Suchith



From: GeoForAll  on behalf of 
Moreno-Sanchez, Rafael 
Sent: 13 October 2019 01:41
To: OsGeo, GeoForAll Subject: [Geo4All] Video 
recording posted GeoForAll lab webinar "mini-conference" Oct 10, 
Hi everyone, 

Thank you again to Charlie and Suchith for leadership and motivation to put 
this mini-conference together.

Thank you to all the presenters for participating and your great presentations.

 

The video recording is posted in the GeoForAll YouTube Channel.

https://youtu.be/Bd8Oe1Z-p3E


In the description of the video is that table of contents of the presentations 
and the corresponding timeline in the video.

 

Please pass the word. I will forward to several mailing lists on Monday.

 

Have a nice weekend. 

Rafael 

 

From: Charlie Schweik 
Sent: Wednesday, October 9, 2019 6:49 AM
To: OsGeo, GeoForAll 
Subject: Reminder! A first GeoForAll lab webinar "mini-conference" tomorrow Oct 
10, 1:00-3:00 GMT, on "GeoForAll contributions to the United Nations 
Sustainable Development Goals"

 

Dear GeoForAll colleagues, 

 

A reminder that a first GeoForAll webinar "mini-conference" will take place 
tomorrow! 
   
   - Topic: "GeoForAll contributions to the United Nations Sustainable 
Development Goals" 
   - Date/time:  Thursday, October 10th from 1-3:00 pm GMT.  
   - What time is it for you? Use this link to find out: 
https://www.timeanddate.com/worldclock/converter.html?iso=20191010T13=tz_gmt
   - Participating GeoForAll labs/members and mini-conference program:
   
   
   - Suchith Anand (Chief Scientist, GODAN)  – Introduction
   - Victoria Rautenbach (GeoForAll chair) – Welcome to GeoForAll
   - Sergio Acosta y Lara (Dirección Nacional de Topografía,Ministerio de 
Transporte y Obras Públicas, Uruguay) -Experiences from the 3rd edition of the 

Re: [Talk-cat] Tipus de nodes a OSM

[Jose Luis Infante]

Bon dia Robert,
a l'estructura de dades d'OSM, els nodes poden tenir etiquetes o no, i
poden formar part de una via o no. Pots tenir nodes que pertanyen a una via
amb etiquetes, com un pas de vianants.
Fent una consulta amb Overpass (https://overpass-turbo.eu/) tens les dades
de la via (way) i les dades dels nodes que pertanyen a la via.

Per exemple, amb aquesta consulta

[out:xml][timeout:50];
{{geocodeArea:"Badalona"}}->.searchArea;
(
way["highway"="living_street"](area.searchArea);
);
(._;>;);
out meta;

Obtens totes les vies living_street i els nodes que les componen:


...



  
...
  














  
...

Quina és la teva idea?

Salutacions!

Jose Luis

El lun., 14 oct. 2019 a las 9:29, Robert Hospital Gasau (<
roberth...@gmail.com>) escribió:

> Bon dia,
> Em podrieu ajudar a clarificar si el que diferència un "node" que actua de
> punt de referència del traçat d'una "way" amb un "node" d'un element
> topogràfic d'interès (amenity, crossing, traffic light, bus stop, etc.) és,
> a banda de que els primers es troben referenciats en els arxius XML de
> "ways" com a punts de referència, l'absència d'informació en les seves
> etiquetes ("tags")?
> Hi ha alguna manera de descarregar únicament els "nodes" que actuen com a
> punt de referència de "ways", sense haver-se de descarregar també la resta
> de "nodes" que donen informació dels punts d'interés?
>
> Moltes gràcies,
> Robert
> ___
> Talk-cat mailing list
> Talk-cat@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cat
>
___
Talk-cat mailing list
Talk-cat@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cat

[Talk-GB] Solar unpopular opinions thread on Twitter

[Jez Nicholson]

Interesting thread for mappers with an interest in solar (last quarterly
project) https://threadreaderapp.com/thread/1183398352148484097.html
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] Ospedali, ambulance_station e altro

[Fra Mauro]

Credo che la situazione sia la stessa di quando si parla della superficie dei 
sentieri escursionistici...

Io lancio due domande sul tagging e faccio una proposta. Mi sforzerò di essere 
pratico! :)

1) vogliamo mappare l'Azienda Ospedaliero Universitaria Pisana ( 
http://www.ao-pisa.toscana.it/) o l'Ospedale di Cisanello 
(https://www.openstreetmap.org/relation/9243476)? Il secondo è quello che la 
persona normale chiama appunto ospedale, la prima è la struttura amministrativa 
che include l'ospedale e che interessa alla P.A. di cui parlava AleZena. Tenete 
presente che una azienda ospedaliera può includere più ospedali, a volte divisi 
anche da qualche km. Inoltre può succedere che l'informazione interessi anche 
al normale cittadino. La lista delle Aziende Ospedaliere è più semplice da 
reperire. Ovviamente la situazione ottimale sarebbe mappare entrambe le cose.

2) vogliamo distinguere l'ospedale dalla clinica? In base al tagging sono tutti 
e due  amenity=hospital...

Proposta. Partiamo dal verificare che tutto quello che è incluso nel file che 
io ho postato sia sulla mappa? Qualche anno fa ho controllato e non era così. 
Quelle nella lista dovrebbero essere le strutture più importanti sul territorio 
italiano.
Questo ha dei pregi:
1) numero limitato di strutture, la cosa è più fattibile
2) si privilegiano le realtà più importanti
3) il dubbio sul tagging rilevante è solamente il primo

Come dicevo io proverò davvero a capire perché realtà come ad esempio 
l'ospedale di Piombino 
(https://uslnordovest.toscana.it/ospedali/40-civile-di-piombino-2) non siano 
nella lista. Purtroppo non posso garantire una risposta in tempi rapidi, questa 
settimana e la prossima saranno molto piene per me.

Il 13 Ottobre 2019 19:15:25 CEST, Francesco Ansanelli  ha 
scritto:
>Buonasera Alessandro,
>
>Vorrei aggiungere anche il mio punto di vista...
>
>Il dom 13 ott 2019, 18:49 Alessandro P. via Talk-it <
>talk-it@openstreetmap.org> ha scritto:
>
>> Accade spesso in questa ML l'inversione di una nota metafora, ovvero
>"il
>> topolino che partorisce la montagna". Si parte con progetti
>> fantasmagorici e la cosa si sgonfia in pochi giorni.
>>
>
>L'ho notato anche io, ma solo quando ci sono problemi più filosofici
>che
>pratici.
>Questa community risponde molto bene a problemi concreti.
>
>>
>> Non se ne abbiano a male i partecipanti a questa discussione in
>> particolare, io alcuni giorni fa avevo preconizzato il destino di
>questa:
>>
>> AUTOCITAZIONE: "Magari si potrebbe iniziare da tutte le Croce qui e
>> Croce là. Qui (per carità Marco, tu sei sempre molto volonteroso)
>> partiamo per costruire le piramidi per fermarci al secchiello di
>sabbia. "
>>
>> come avvenuto per moltissime altre discussioni in passato.
>>
>> Il mio approccio era di tenere un basso profilo, senza voler
>sistemare
>> definitivamente il problema ma almeno iniziare ad affievolirlo:
>>
>> 1) se si vede un POI con la scritta "Croce di qualsiasi colore" posta
>> in, o accanto, un edificio che con nessuna probabilità possa essere
>un
>> ospedale mettiamoci emergency=ambulance_station (o in logica inversa
>> qualcuno ritiene che è meglio lasciare questa informazione)?
>>
>
>Ci sono molte croci x o y taggate come hospital? Serve uno strumento
>per
>segnalare il problema a chi mappa. Possiamo fare una regola di JOSM che
>proponga di sostituire il tag con ambulance station.
>
>
>> 2) se un edificio costituito da diverse parti su ognuna di esse
>troviamo
>> il tag amenity=hospital lasciamolo solo su una.
>>
>
>Amenity hospital non va usato sugli edifici... E non vale solo per
>l'Italia:
>How to map
>
>Draw an area [image: area] 
>around
>the grounds of the hospital, and add the amenity
>=hospital tag to it.
>If
>the area is no known, add a node [image: node]
> at the centre of the
>hospital.
>
>>
>> Già in questo modo si risolverebbe la grande percentuale di falsi
>ospedali.
>>
>
>Perfettamente d'accordo! Anche perché se trovo un errore magari mi
>attivo
>per controllare tutta la zona.
>
>
>> Ma ci pensate se il ministero lanciasse una query sul territorio
>> italiano per contare il numero di ospedali? Il giorno dopo su tutti i
>> giornali leggeremmo che il 50% degli ospedali verrebbero chiusi :-)
>> E' meglio che scriva esplicitamente che si tratta di un'iperbole.
>> Ma una P.A., con quale coraggio dovrebbe usare dati OSM se non
>riusciamo
>> a contenere un minimo questi errori macroscopici?
>>
>> Con poche speranze di qualsivoglia risultato saluto tutti
>>
>
>Buona serata!
>Francesco
>
>>
>> Alessandro Ale_Zena_IT
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>

-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.___
Talk-it mailing list

[Talk-it] Ospedali, ambulance_station e altro

[Lorenzo Pesci]

  Nella mia zona ho trovato sospetto 

questo inserimento:
6 ospedali
mappati e nessuna corrispondenza sul web

Come quello segnalato da
A.Palmas, anche questo è dell'utente mcheck
.
https://www.openstreetmap.org/way/712913302#map=18/43.18101/11.98406

Non
ne so abbastanza però per andare a modificare con sicurezza 
(a parte
riunire 6 [amenity hospital] in una unica area).

L.Pesci

> Message:
1
> Date: Wed, 9 Oct 2019 21:26:50 +0200
> From: "Alessandro P." 
> To:
openstreetmap list - italiano 
> Subject: [Talk-it] Ospedali,
ambulance_station e altro
> Message-ID: 
> Content-Type: text/plain;
charset=iso-8859-15; format=flowed
> 
> Ciao lista,
> tanti anni fa
avevamo provato a lanciare un'iniziativa di mappatura al mese.
> 
>
Vista la situazione degli ospedali, o presunti tali, mappati in Italia,

> perché non cerchiamo almeno di sistemare i casi più palesi?
> 
> In
Liguria ho trovato molte stazioni di ambulanza, e addirittura un 
>
centro addestramento cinofilo (1) come hospital.
> Un classico caso sono
3 tag amenity hospital, uno per il perimetro, 
> l'altro per l'edificio
principale e il terzo per il pronto soccorso.
> 
> Almeno su queste cose
che dovrebbero essere importanti un piccolo sforzo 
> lo vogliamo
fare?
> 
> Alessandro Ale_Zena_IT
> 
>
1)https://www.openstreetmap.org/node/2774569646 [4]
> 
>
--
  


Con Tiscali Mobile Smart 30 hai minuti illimitati, 30 Giga e 100 SMS a soli 
7,99€ al mese. L'attivazione è gratis e disdici quando vuoi. 
http://tisca.li/smart30

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

[OSM-talk-fr] Tour antigel

[Yves P.]

Bonjour,

Comment cartographier une tour antigel, machine à vent, wind machine ?

Ces tours sont érigées dans les vergers, vignes…
De loin, ça peut ressembler à une éolienne à 2 pales…

Une seule photo (de son pied) 

 dans wikimedia commons, rien dans OSM.

J’en ai trouvé qu'une seule dans taginfo (node 3958519692 
), mais la vue routière 
correspond à une petite éolienne au sommet d’une perche.
man_made=tower
tower:type=wind_generator

tower:type=wind_machine ?
tower:type=antifreeze ?
tower:type=antifrost ?

https://www.tour-antigel.com

Pour info, j’ai utilisé wind_machine pour le moment : noeuds 6877573656 
, 6877573657 


—
Yves

PS: c’est décrit par la FAO : http://www.fao.org/3/y7223e/y7223e0d.htm




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

Re: [Talk-at] OSM Nutzung in Buch ohne Nennung

[various]

Ich versteh es zwar, fände es aber nicht schlecht, wenn der Verlag zumindest 
darauf hingewiesen wird. Dann ist es vielleicht so, dass bei einer neuen 
Auflage oder bei einem neuen Buch auf so etwas geachtet wird. Sonst kommt 
irgendwann später beim nächsten mal vielleicht ein "Aber bei dem Buch hattet 
ihr keine Probleme damit..." oder so. (Was natürlich auch keine Ausrede sein 
kann/darf.)

Es geht ja nicht um Anschuldigungen oder großartige Sachen, sondern mehr um den 
grundsätzlichen Hinweis. "Wir haben leider erst jetzt bemerkt, dass ihr das 
benutzt und haben uns sehr gefreut, dass es verwendet wird. Allerdings haben 
wir gesehen, dass leider der Uhrheberrechtshinweis auf OSM im Buch wohl 
übersehen wurde. Die korrekte Art das zu machen ist zum Beispiel hier(link) 
und/oder hier (link) zu finden, blabla, vielen Dank, und so weiter."

Oder so. 

> Friedrich Volkmann  hat am 14. Oktober 2019 um 00:34 
> geschrieben:
> 
> 
> On 13.10.19 23:57, Michael Reichert wrote:
> > Die Kartenbilder sind nämlich recht alt und zeigen eine mehrere Jahre
> > alte Version des Kartenstils OSM Carto oder noch seinen Vorgänger den
> > Mapnik-OSM-Stil.
> 
> Marcus hat inzwischen klargestellt, dass das Buch aus 2014 ist.
> 
> > Angesichts des Alters der Daten und des stark heruntergesetzten Preises
> > würde ich den Fall gar nicht weiterverfolgen. Ich vermute, dass da ein
> > Ladenhüter verramscht werden soll. Das ist unsererseits den Aufwand
> > nicht wert.
> 
> Das sehe ich auch so. (Rechtlich möglich wär es aber. Die Verwertungsrechte 
> verjähren erst 70 Jahre nach dem Tod des Urhebers.)
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at

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

Re: [OSM-talk-fr] Sur 01net L’incroyable histoire de Waze, la carte routière la plus précise au monde... conçue par des bénévoles

[Vincent Bergeot]

Le 06/10/2019 à 10:45, PierreV a écrit :

https://www.01net.com/actualites/l-incroyable-histoire-de-waze-la-carte-routiere-la-plus-precise-au-monde-concue-par-des-benevoles-1777628.html

On contacte 01net pour leur proposer un article sur OSM qui est encore plus
"génial" que Waze car réutilisable par n'importe qui?



il y a quelque temps, alors que l'on parlait de Waze comme le nouveau 
Wikipédia de la cartographie (!!!), nous avions commencé cela : 
https://mypads.framapad.org/mypads/?/mypads/group/osm-fr-upup77pw/pad/view/waze-n-est-pas-le-wikipedia-de-la-carto-k91j0b7c5


peut-être que nous pourrions continuer le texte pour rappeler qu'il y a 
quelques différences assez fondamentales !


à plus

--
Vincent Bergeot


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

[Talk-hr] Pomoc oko oznacavanja zona pokrivenosti

[hbogner]

Treba mi pomoć oko označavanja zona pokrivenosti DGU podlogama

Na osm-hr blogu su dva članka sa linkovima na wms servise DGU-a

- 
https://osm-hr.org/2019/06/04/pravo-koristenja-mreznih-usluga-prostornih-podataka-drzavne-geodetske-uprave/
- 
https://osm-hr.org/2019/07/11/objavljen-digitalni-ortofoto-drzavne-geodetske-uprave-2018/


Trebaju nam poligoni koji označavaju pokrivenost određenim podlogama kao 
na 
https://github.com/osmlab/editor-layer-index/tree/gh-pages/sources/europe/hr


Projekt je privremeno forkan u osm-hr pa možete tamo direktno pushati
https://github.com/osm-hr/editor-layer-index/tree/gh-pages/sources/europe/hr

HOK ja rješavam, ali trebaju nam RGI, te svi DOF-ovi da završimo sve DGU 
slojeve s aliste: https://github.com/osm-hr/osm-hr/issues/60




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

Re: [OSM-talk-fr] CyclOSM, rendu cyclable libre

[Phyks]

> Y a t-il une difficulté particulière pour que la couche avec relief ne
> soit pas disponible sur le quart sud est de la France ?
> https://www.cyclosm.org/#map=6/44.088/6.240/cyclosm_relief

La couche avec relief actuellement présente est là juste pour donner un
aperçu actuellement. Ce sont de vieilles données et la couverture
spatiale est limitée.

La raison étant qu'on n'a pas pu remettre le relief en place
immédiatement en déplaçant vers les serveurs OSM-Fr. On a la plupart des
fichiers nécessaires et cette couche va donc prochainement disparaître
pour être fusionnée dans le rendu "de base" :)

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