[talk-au] Ways to map boundaries that won't go into OSM

[Ben Kelley]

Hi.

A project I have been thinking about for a while is creating a map of
Anglican (church) parish boundaries in Australia.

In some sense these are like admin boundaries, but the source of the
boundary is not easily verifiable. While the resulting map would be based
on OSM, the data itself probably does not belong in OSM.

Any thoughts on a tool set for how to do this?

I'm after ideas for a way for people to edit this data, ways to store it,
ways to display it online, and ways to make a printed map (if necessary).

The source data in some areas can be written, like "The boundary runs north
from the end of Railway Parade until it crosses the creek." The person
editing this map would use OSM to draw the boundary (making it a derivative
work), possibly for display as a layer on top of OSM data.

If I needed to stand up a server to store edits, that's a possibility. Is
it possible to integrate existing editing UI tools with a different back
end, or would this require people to use JOSM?

In the past some people have done similar using Google's tool set, but then
the resulting maps are derivatives of Google's base map, which creates
problems if you want to reproduce that map outside of Google Maps.

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

Re: [Talk-at] Hausnummern + Hauseingänge / Adressen in Wien?

[Friedrich Volkmann]

On 17.06.19 03:28, Kevin Kofler wrote:

Friedrich Volkmann wrote:

Wie Robert Kaiser schon angemerkt hat, war das einst Konsens für Häuser
mit mehreren Adressen. Heute gibt es dafür was Besseres, nämlich das
addrN-Schema.


Das addrN-Schema ist aber nicht Konsens und ist aufgrund der fehlenden
räumlichen Positionierung der verschiedenen Adressen für Rendering völlig
ungeeignet und für Routing nur bedingt geeignet.


Der oben erwähnte Konsens sah so aus, dass Andreas Labres bei einem 
Stammtisch mit lauter Stimme sagte, wie etwas gemacht gehört, und dann haben 
es alle so gemacht. In Wien halt. Aber OSM gibt es nicht nur in Wien, und 
wir können auch mal über dir Grenzen schauen, wie andere es machen. 
addr2:housenumber kommt 14414 mal vor. Das kann man schon als de-facto 
Standard ansehen.


Für Rendering ist es sehr wohl geeignet, das hab ich ich schon vor vielen 
Jahren im Zuge des Proposals im Detail erklärt. Ein Renderer braucht nur 
schauen, auf welcher Seite des Hauses eine Straße dieses Namens existiert, 
und dort die Hausnummer platzieren. Was das Routing betrifft, da ist es 
sowieso absurd, jemanden zu einem bestimmten Hauseingang zu routen. Für 
Fußgängerrouting kommt es darauf an, auf kürzestem Weg zum Haus hinzukommen 
und dann möglichst durch einen Eingang auf der Seite, von der man kommt, ins 
Haus hineinzugehen. Keiner will auf einen Umweg um das Haus herum geschickt 
werden. Fürs Kfz-Routing gilt im Prinzip das gleiche, außerdem wird man 
sowieso selten genau vorm Eingang einen Parkplatz bekommen. Es ist dann also 
erstrebenswert, vom Router das Haus als Ziel angezeigt zu bekommen, damit 
man auf der Suche nach einem Parkplatz um das Haus herum fahren kann.


Und seien wir uns ehrlich: Eigentlich ist das alles Hirnw*xerei ("eine 
akademische Diskussion"), denn wenn ein Ziel so weit weg ist, dass man ohne 
Routing nicht hinfindet, dann wird es keinem auf die paar Sekunden ankommen, 
die man am Schluss zum Eingang hingeht. Wenn man sich in solche Diskussionen 
verliert, dann verliert man zugleich auch den Bezug zu den wirklichen 
Bedürfnissen der Anwender.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [talk-au] Suspicious or disallowed sources

[Adam Horan]

I have dropped a changeset comment already, and will wait a bit longer. I
don't see that the user is making other changes currently.

There's too much detail in the shape for it to be sourced from a vague
ground survey, and for the sports tracks in this changeset there is nothing
in the available iD imagery.

To be honest it was the direct reference to 'nearmap' as a source in
something drawn ~1 month ago that got me started on this.

Adam

On Mon, 17 Jun 2019 at 13:51, Andrew Harvey 
wrote:

> I agree it's best to ask via a changeset comment first. It could be they
> observed where it was on the ground, then lined that up with what they
> could reference in the Bing imagery.
>
> On Mon, 17 Jun 2019 at 13:39, Phil Wyatt  wrote:
>
>> Hi Adam,
>>
>>
>>
>> First thing I would do is drop a comment on the changesets asking where
>> he got the outlines from – there may be some other ‘open’ source that he
>> has used.
>>
>>
>>
>> Cheers - Phil
>>
>>
>>
>> *From:* Adam Horan [mailto:aho...@gmail.com]
>> *Sent:* Monday, 17 June 2019 1:26 PM
>> *To:* OpenStreetMap-AU Mailing List
>> *Subject:* [talk-au] Suspicious or disallowed sources
>>
>>
>>
>> Hi,
>>
>>
>>
>> I've been around a while, but don't join in the chat much :)
>>
>>
>>
>> A new user has added contributed some data via iD editor, and the source
>> is listed as Bing Imagery. However the imagery doesn't show the features
>> that have been added as they're too new. (I've checked through all other
>> imagery sources in iD)
>>
>> One of their contributions from within the last month lists nearmap as
>> the source. It is quite possible this is true, as again none of the listed
>> imagery sources in iD or JOSM include the features added.
>>
>> I've attempted to contact the user (it's only been 24 hrs since i tried),
>> and had nothing yet.
>>
>>
>>
>> Is this a revert or wait scenario?
>>
>>
>>
>> https://www.openstreetmap.org/changeset/69893632  <- the car park and
>> the soccer pitches are not in Bing or elsewhere. Google does have it.
>>
>>
>>
>> https://www.openstreetmap.org/changeset/69917230 <- running track not in
>> bing or elsewhere.
>>
>>
>>
>> Cheers,
>>
>>
>> Adam
>> ___
>> 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
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Suspicious or disallowed sources

[Andrew Harvey]

I agree it's best to ask via a changeset comment first. It could be they
observed where it was on the ground, then lined that up with what they
could reference in the Bing imagery.

On Mon, 17 Jun 2019 at 13:39, Phil Wyatt  wrote:

> Hi Adam,
>
>
>
> First thing I would do is drop a comment on the changesets asking where he
> got the outlines from – there may be some other ‘open’ source that he has
> used.
>
>
>
> Cheers - Phil
>
>
>
> *From:* Adam Horan [mailto:aho...@gmail.com]
> *Sent:* Monday, 17 June 2019 1:26 PM
> *To:* OpenStreetMap-AU Mailing List
> *Subject:* [talk-au] Suspicious or disallowed sources
>
>
>
> Hi,
>
>
>
> I've been around a while, but don't join in the chat much :)
>
>
>
> A new user has added contributed some data via iD editor, and the source
> is listed as Bing Imagery. However the imagery doesn't show the features
> that have been added as they're too new. (I've checked through all other
> imagery sources in iD)
>
> One of their contributions from within the last month lists nearmap as the
> source. It is quite possible this is true, as again none of the listed
> imagery sources in iD or JOSM include the features added.
>
> I've attempted to contact the user (it's only been 24 hrs since i tried),
> and had nothing yet.
>
>
>
> Is this a revert or wait scenario?
>
>
>
> https://www.openstreetmap.org/changeset/69893632  <- the car park and the
> soccer pitches are not in Bing or elsewhere. Google does have it.
>
>
>
> https://www.openstreetmap.org/changeset/69917230 <- running track not in
> bing or elsewhere.
>
>
>
> Cheers,
>
>
> Adam
> ___
> 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

Re: [talk-au] Suspicious or disallowed sources

[Phil Wyatt]

Hi Adam,

 

First thing I would do is drop a comment on the changesets asking where he got 
the outlines from – there may be some other ‘open’ source that he has used.

 

Cheers - Phil

 

From: Adam Horan [mailto:aho...@gmail.com] 
Sent: Monday, 17 June 2019 1:26 PM
To: OpenStreetMap-AU Mailing List
Subject: [talk-au] Suspicious or disallowed sources

 

Hi,

 

I've been around a while, but don't join in the chat much :)

 

A new user has added contributed some data via iD editor, and the source is 
listed as Bing Imagery. However the imagery doesn't show the features that have 
been added as they're too new. (I've checked through all other imagery sources 
in iD)

One of their contributions from within the last month lists nearmap as the 
source. It is quite possible this is true, as again none of the listed imagery 
sources in iD or JOSM include the features added.

I've attempted to contact the user (it's only been 24 hrs since i tried), and 
had nothing yet.

 

Is this a revert or wait scenario?

 

https://www.openstreetmap.org/changeset/69893632  <- the car park and the 
soccer pitches are not in Bing or elsewhere. Google does have it.

 

https://www.openstreetmap.org/changeset/69917230 <- running track not in bing 
or elsewhere.

 

Cheers,


Adam

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

[talk-au] Suspicious or disallowed sources

[Adam Horan]

Hi,

I've been around a while, but don't join in the chat much :)

A new user has added contributed some data via iD editor, and the source is
listed as Bing Imagery. However the imagery doesn't show the features that
have been added as they're too new. (I've checked through all other imagery
sources in iD)
One of their contributions from within the last month lists nearmap as the
source. It is quite possible this is true, as again none of the listed
imagery sources in iD or JOSM include the features added.
I've attempted to contact the user (it's only been 24 hrs since i tried),
and had nothing yet.

Is this a revert or wait scenario?

https://www.openstreetmap.org/changeset/69893632  <- the car park and the
soccer pitches are not in Bing or elsewhere. Google does have it.

https://www.openstreetmap.org/changeset/69917230 <- running track not in
bing or elsewhere.

Cheers,

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

Re: [Talk-at] Hausnummern + Hauseingänge / Adressen in Wien?

[Kevin Kofler]

Friedrich Volkmann wrote:
> Wie Robert Kaiser schon angemerkt hat, war das einst Konsens für Häuser
> mit mehreren Adressen. Heute gibt es dafür was Besseres, nämlich das
> addrN-Schema.

Das addrN-Schema ist aber nicht Konsens und ist aufgrund der fehlenden 
räumlichen Positionierung der verschiedenen Adressen für Rendering völlig 
ungeeignet und für Routing nur bedingt geeignet.

Kevin Kofler


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

Wochennotiz Nr. 464 04.06.2019–10.06.2019

[Wochennotizteam]

Hallo,

die Wochennotiz Nr. 464 mit vielen wichtigen Neuigkeiten aus der
OpenStreetMap-Welt ist da:

http://blog.openstreetmap.de/blog/2019/06/wochennotiz-nr-464/

Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz
einreichen könnt, ohne Mitglied zu sein?  Einfach auf
https://osmbc.openstreetmap.de/login mit eurem OSM-Benutzerkonto
anmelden und dann den Gastzugang benutzen.

Viel Spaß beim Lesen

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

[Talk-it] "Tralicci" trasversali e catenarie ferroviarie

[francesco gargano]

 Salve a tutti,chiedo agli appassionati del ramo railways ed affini
soprattutto:quando ci troviamo di fronte a grandi strutture di tralicci
trasversali che reggono i supporti delle catenarie, come questi [1] [2] [3]
[4] che nel caso specifico sono a Roma Termini, e sovrastano praticamente
tutte quante le sedi dei binari,
oppure  di fronte a grandi strutture  che reggono i semafori di
segnalamento come questa [5]; vi chiedo ma a tutto ciò è applicabile
power=portal o esistono altri "oggetti" più specifici? Per i pali singoli
avevo trovato power=catenary_mast ma mi sembra dedicato ai singoli pali
verticali e non a strutture più grandi come queste

[1] https://www.mapillary.com/map/im/AHXUvOmGhqAdQHavhyHfdw
[2] https://www.mapillary.com/map/im/_19JZUSUmGSteaUdKhCAaw
[3] https://www.mapillary.com/map/im/nE69DnZvjCXb7Jmr4Mzp-w
[4] https://www.mapillary.com/map/im/4-Mn2s3-Ks4pRJrLdHMsxQ
[5] https://www.mapillary.com/map/im/8tx0PWPNi22oG7jBQmpJ2w
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Modifier le commentaire d'un changeset ?

[Cédric Frayssinet]

Merci  à tous les 2, j'ai donc commenté mon changeset ; pas très propre
mais ce n'est pas trop grave.

Cédric

Le 16/06/2019 à 20:18, osm.sanspourr...@spamgourmet.com a écrit :
>
> Non mais tu peux commenter ton propre changeset.
>
> Sauf peut-être si ton changeset n'est pas fermé. Je pense que le
> commentaire qui reste c'est le premier mais tu peux éventuellement tenter.
>
> Jean-Yvon
>
> Le 16/06/2019 à 19:51, Cédric Frayssinet - lis...@frayssinet.org a écrit :
>> Bonjour à tous,
>>
>> Tout est dans le titre. Est-il possible de modifier le commentaire d'un
>> changeset, j'ai cliqué un peu trop vite sur la validation :(
>>
>> Merci, Cédric
>>
>>
>> ___
>> 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

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

[Talk-lt] Pastaba: Karinė teritorija Kaune

[Tomas Straupis]

Sveiki

  Gal kauniečiai gali padėti sutvarkyti šitą pastabą?
  https://www.openstreetmap.org/note/1620505
  Ačiū

-- 
Tomas

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

Re: [OSM-talk-fr] Modifier le commentaire d'un changeset ?

[osm . sanspourriel]

Non mais tu peux commenter ton propre changeset.

Sauf peut-être si ton changeset n'est pas fermé. Je pense que le
commentaire qui reste c'est le premier mais tu peux éventuellement tenter.

Jean-Yvon

Le 16/06/2019 à 19:51, Cédric Frayssinet - lis...@frayssinet.org a écrit :

Bonjour à tous,

Tout est dans le titre. Est-il possible de modifier le commentaire d'un
changeset, j'ai cliqué un peu trop vite sur la validation :(

Merci, Cédric


___
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] Modifier le commentaire d'un changeset ?

[marc marc]

Non, mais tu peux commenter le changeset

> Le 16 juin 2019 à 19:53, Cédric Frayssinet  a écrit :
> 
> Bonjour à tous,
> 
> Tout est dans le titre. Est-il possible de modifier le commentaire d'un
> changeset, j'ai cliqué un peu trop vite sur la validation :(
> 
> Merci, Cédric
> 
> 
> ___
> 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-at] Hausnummern + Hauseingänge / Adressen in Wien?

[Friedrich Volkmann]

On 16.06.19 13:23, realadry via Talk-at wrote:

Ich bin zwar schon mehrere Jahre bei OSM aber habe das Thema nicht
regelmäßig verfolgt, daher weiß ich nicht ob es mittlerweile einen
Konsens gibt.


Nein, gibt es nicht.


Wenn man sich in der Karte in Wien umsieht, sieht man drei verschiedene
Arten wie Hausnummern gemapped werden:

1) Eigener Node mit der gesamten Adresse. Gebäude Polygon hat gar keine
Adressinformation. Dieser Node ist manchmal in der Nähe des
Hauseinganges, manchmal irgendwo innerhalb der Gebäudes platziert.


Wie Robert Kaiser schon angemerkt hat, war das einst Konsens für Häuser mit 
mehreren Adressen. Heute gibt es dafür was Besseres, nämlich das addrN-Schema.



2) Hausnummer und Adresse am Gebäudepolygon. (Eingang als Node des
Gebäudes.)


Das ist grundsätzlich die richtige Metode.


3) Hausnummer, Adresse und Eingang auf einem Node der Teil des Gebäude
Polygons ist, an der Stelle des Hauseingangs.


Das war nie Konsens und zeugt von einer grundlegend falschen Sichtweise, s.u.


Variante 1:
Eine Adresse die "irgendwo" als einzelner Node im Gebäude herumfliegt
hat keinen Sinn, da man überlicherweise eine Adresse auch mit dem
Eingang assoziiert


Tust du das wirklich? Wo wohnst du, dass du dir so eine Sichtweise 
angeeignet hast? Eine Hausnummer ist, wie der Name schon sagt, die Nummer 
eines Hauses, nicht eines Eingangs. Eigenschaften eines Hauses sind 
logischerweise aufs Haus zu taggen. Du setzt ja wohl auch nicht den Namen 
einer Firma nur auf den Eingang zum Firmengelände oder die Nummer einer 
Autobahn nur auf die Auffahrt.



(Hausnummer ist ja in Realität fast immer am Eingang
angebracht).


Ja, zur Orientierung. Genauso wie das Schild am Eingang zum Firmengelände 
oder die Tafel bei der Autobahnauffahrt.


Es gibt genug Beispiele für Hausnummernschilder, wo kein Eingang ist, und 
für Eingänge, wo kein Hausnummernschild hängt. Es würde schon ein einziges 
Gegenbeispiel reichen um eine Theorie zu widerlegen, und hier gibt es 
Gegenbeispiele en masse.



Bei dieser Variante kann weder das Gebäude polygon, noch
der Hauseingangs-node festgestellt werden. Es wird zum Ratespiel.


Doch, beides kann festgestellt werden. Soweit ich weiß, bietet PostGIS schon 
vorgefertigte Funktionen dafür um herauszufinden, ob ein bestimmter Node 
innerhalb eines bestimmten Polygons liegt. Aber das war gar nicht der Zweck 
dieser Variante 1. Es ging nur darum, Identadressen überhaupt erfassen zu 
können und dem Renderer zu sagen, auf welcher Seite des Hauses er die 
Hausnummer anzeigen soll.



Variante 2:
Hier kann man immerhin den Eingang noch mit der Adresse assozieren, da
man einfach den "Eingang" node am jeweiligen Gebäude Polygon auslesen
muss (das man zuvor anhand der Adresse gefunden hat).


Ja, mit Variante 2 funktioniert alles.


Variante 3:
In jeder Hinsicht die logischste. Eingang, Adresse, Gebäude ist alles
einfach maschinell auszulesen.


Nein, s.o. (Gegenbeispiele), und für eine Trafik x im Gebäude y mit Adresse 
z muss eine Anwendung erst den Haupteingang (der gar nicht in die Trafik 
führt), das Gebäude und den POI für die Trafik einander zuordnen. 
Komplizierter geht es nicht.


Wenn ein entrance-Node Eingang zu 2 verschiedenen Flächen gleichzeitig ist 
(z.B. building und building:part), dann scheitert eine automatische 
Zuordnung überhaupt, denn in so einem Fall ist undefiniert, auf welche der 
Flächen sich die Adresse bezieht. Das ist halt das Problem, wenn man 
Attribute nicht auf das Objekt setzt, auf das sie sich beziehen.



Für das Rendern macht es keinen Unterschied welche Variante gewählt
wird.


Doch, das ist sogar der sich am meisten praktisch auswirkende Unterschied. 
Wenn die Adresse aufs Gebäude gesetzt ist, wir sie in der Gebäudemitte 
gerendert. Wenn die Adresse auf einen Node gesetzt ist, wird sie dort 
gerendert, wo der Node ist.



Zum Routen und zur maschinellen verarbeitung (Suche) aber sehr wohl.


Im Moment können die gängigen Anwendungen alle 3 Varianten nicht richtig, 
obwohl es für alle 3 Varianten nicht schwierig wäre. Bisher hat halt keiner 
einen Bedarf gesehen, es ordentlich zu programmieren.



Jetzt fragt ihr euch vielleicht, warum mir das so wichtig ist. Ganz
einfach. Abgesehen von Routingproblem um den Eingang zu finden. Um
effizient und maschinell gewisse Bearbeitungen oder Suchen vorzunehmen,
muss man mit Gewissheit die Adresse eines Gebäudes feststellen können.

z.B. Eine Liste von Adressen von Gebäuden mit gewissen Merkmalen die man
eintragen möchte oder eine Liste von Adressen von denen man das
zugehörige Gebäudepolygon markieren/ausgeben möchte.
Suche ich nach der Adresse, finde aber nur einen Knoten der im nichts
herumschwebt (wie Variante 1), ist das ein Problem für ein Skript.


Heißt das, du bist Anwendungsentwickler? Dann wird dir nichts anderes übrig 
bleiben, als dein Programm so zu schreiben, dass es mit allen 3 Varianten 
umgehen kann. Denn als Anwendungsentwickler musst du mit den Daten leben, 
die du vorgesetzt bekommst.


--

[OSM-talk-fr] Modifier le commentaire d'un changeset ?

[Cédric Frayssinet]

Bonjour à tous,

Tout est dans le titre. Est-il possible de modifier le commentaire d'un
changeset, j'ai cliqué un peu trop vite sur la validation :(

Merci, Cédric


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

[Talk-ko] 주간OSM #464 미리보기 및 보충 설명

[Dongha Hwang]

1. Maarten van den Hoven이 제작한 Mapping North Korea가 주간OSM에 올라왔습니다.


2. K_sakanoshita가 인쇄용 지도를 제작할 때 사용하기 좋은 "거리 산책 지도 메이커(まち歩きマップメーカー)"를
업데이트했습니다.  해당 사이트는 이전에
제 블로그에서도 언급한 적 있습니다.  인터페이스가 단순하면서도 자주
쓰는 기능은 착실히 담아 놓은 좋은 사이트인데, 일본어만 지원되는 것은 개인적으로 약간 아쉽습니다.
이건 여담이지만, 의외로 지도 스크린샷이 약관에 위배되는 경우가 많다는 것을 아시는 분도 있긴 있더라고요(카카오
와 구글
의 경우 허가를 받아야 함, 네이버의 경우
지도에 선을 긋는 등 편집하지만 않으면 저작자를 표시하는 조건으로 이용 가능
.
다만 창작성이 인정되지 않는 수준의 지도는 저작권이 인정되지 않는다는 대법원 판례가 있다고 하니
, 약관 위반이 저작권 침해로 이어진다고 볼 순
없겠습니다). "저작권 없는 지도"로 검색해서 들어오는 사람들이 종종 있더라고요. 물론 저작권이 없는 건 아니지만 ODbL의 약관이
널널한 건 사실이니...

※ 위 기사들은 주간OSM #463 한국어판이 올라오면 한국어로 볼 수 있습니다. 그 전에는 영어로 나타납니다.
ᐧ
___
Talk-ko mailing list
Talk-ko@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ko

Re: [OSM-talk-fr] Traiteur

[marc marc]

Le 16.06.19 à 12:25, Muselaar a écrit :
> un tel établissement peut-il décemment être appelé restaurant ?

un POI oü tu ne peux pas manger sur place n'est à mes yeux pas un 
restaurant, c'est un magasin alimentaire ou n'importe quoi du genre
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-at] Hausnummern + Hauseingänge / Adressen in Wien?

[Robert Kaiser]

realadry via Talk-at schrieb:

1) Eigener Node mit der gesamten Adresse. Gebäude Polygon hat gar keine
Adressinformation. Dieser Node ist manchmal in der Nähe des
Hauseinganges, manchmal irgendwo innerhalb der Gebäudes platziert.

2) Hausnummer und Adresse am Gebäudepolygon. (Eingang als Node des
Gebäudes.)

3) Hausnummer, Adresse und Eingang auf einem Node der Teil des Gebäude
Polygons ist, an der Stelle des Hauseingangs.


Die bisherige gängige Übereinkuft der Wiener Community war/ist Variante 
2 zu verwenden, wenn es nur eine Adresse für das Gebäude gibt, und 
Variante 1 (mit dem Punkt in der Nähe des Eingangs, falls bekannt), wenn 
es mehrere gibt (was bei Eckhäusern in Wien sehr oft der Fall ist).
Variante 3 ist zwar im letzteren Fall gut, wenn man präzise Punkte für 
Eingänge kennt, aber aufwändiger - mal abgesehen davon, dass die 
aktuellen Renderer damit nicht gut umgehen können (aber wir taggen ja 
nicht für den Renderer).
Wo ein Gebäude einer Adresse entspricht, ist Variante 2 aber ziemlich 
durchgehend die bessere Variante, da die Adresse dort für alle möglichen 
Eingänge korrekt ist.
Die Behandlung von Adressen, die für verschiedene Gebäudeteile, -seiten, 
oder -eingänge verschieden sind, ist generell ein vieldiskutiertes 
Thema, zu dem es keine wirklich fixierten Regeln gibt, nur lose 
Übereinkünfte zwischen Communitymitgliedern.


Im Zweifel ist es jedenfalls besser, Daten zu vervollständigen, wo noch 
keine sind, bevor man sich die Arbeit macht, von einem "System" auf das 
andere "umzutaggen".


Grüße,
Robert


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

Re: [Talk-at] minderwertige Importe

[various]

Noch eine Ergänzung:
Laut seinem Blog ist die Sperre ja mehr oder weniger eh egal. 
https://addresshistory.wordpress.com/2019/06/11/openstreetmap-und-die-verschworung/#comment-179
Zitat:
"addresshistory
13. Juni 2019 um 08:29

Die derzeitige Sperre ist lediglich technisch bedingt. Wenn Du innerhalb von 
wenigen Tagen 200.000 Adressen oder mehr hinzufügst benötigt solches eine 
Aufarbeitung. Eine andere Variante wäre einen solchen Import vorher zu klären. 
Es gab aber im Webforum zu wenig Rückmeldung. Eine solche Diskussion ins Talk 
Forum zu zwingen, da könnte man eine Vs erkennen. Tu ich aber in diesem Fall 
noch nicht, da dort gegenständlich nur bekannte Personen in Erscheinung 
getreten sind."

Zum Thema der Sperre und den Reverts hat sich Luzandro im Forum extrem viel 
Arbeit gemacht und versucht das aufzuarbeiten und ein paar Sachen dazu zu 
erklären:
https://forum.openstreetmap.org/viewtopic.php?id=66457


Er versucht auch Namen und Pseudonyme zu Verknüpfen, keine Ahnung, ob das jedem 
so recht ist:
https://addresshistory.wordpress.com/2019/06/16/talk-aktive-osm-pseudonyme/


> vari...@mailbox.org hat am 16. Juni 2019 um 18:04 geschrieben:
> 
> 
> Servus, 
> 
> die Sache mit Johann ist die, er macht selten etwas wirklich schlechter, er 
> bringt ja durchaus SEHR viele Adressen ein, was auch gut ist und OSM 
> weiterbringt.
> Er importiert einfach blindlings (früher hatte er behauptet, er importiert 
> nicht, deswegen muss er die Import-Regeln nicht beachten), jetzt sagt er 
> zwar, dass er importiert, hält sich aber trotzdem nicht an die Import-Regeln. 
> Das Hauptproblem ist nicht zwingend, dass er etwas schlechter macht, er macht 
> es einfach nur schlecht und damit halst er sich selbst und anderen doppelte 
> Arbeit auf. Wenn er das ordentlich vorher besprochen hätte, könnte vieles 
> VIEL entspannter ablaufen.
> Von seinen Imports sind wohl 80-90% oder so korrekt ausgeführt, Nummern auf 
> den Gebäuden und so weiter. Der Rest sind halt Hausnummer enter klar 
> erkennbar auf Nebengebäuden oder irgendwo auf Feldern verteilt. Und das ist 
> einfach laufend so, darauf hingewiesen kommt halt meist eine patzige Antwort 
> retour und ein "Mache ich irgendwann!".
> 
> Letztens hat er wohl massenhaft "leere" Nodes gelöscht, da hat er wohl wieder 
> einen Filter angesetzt und großzügig gelöscht über große Flächen.
> 
> Letzte Sachen grundsätzlich reverten? Nein. In Spezialfällen vielleicht, es 
> wurde ja auch schon einiges hinterhergeräumt, behaupte ich mal. Die Sperre? 
> Sehr gut, vielleicht kann man ihn so mal dazu zwingen, sich hier und/oder im 
> Forum zu melden um das vorher zu diskutieren. 
> Wird er das machen? Ich glaube nicht. Er wird die Daten herunterladen, in 
> JOSM bearbeiten, warten bis die Sperre abläuft und dann alles hochladen. 
> (sollte afaik ja gehen, die Sperre hindert ja nur am hochladen, nicht am 
> runterladen).
> 
> Zusätzlich versucht er fleissig Diskussionen auf seinen eigenen externen Blog 
> auszulagern, damit er unliebsame Sachen löschen kann.
> 
> Und, völlig klar macht er das im glauben, OSM besser zu machen.
> 
> Zur Holzhammersache: Nunja, er wurde sehr oft darauf hingewiesen, auch in 
> diversen Changesetkommentaren von der DWG, es ist jetzt nicht so die 
> Überraschung...
> Und Österreichweit treibt er sich schon ziemlich lang herum, nicht erst seit 
> 2 Wochen.
> 
> Lg
> 
> > Georg Haefele  hat am 11. Juni 2019 um 11:21 
> > geschrieben:
> > 
> > 
> > Hallo,
> > 
> > also ich finde die Arbeit von Johann sehr wertvoll. Er hat zumindest in 
> > meiner Heimatgemeinde in Vorarlberg gute Arbeit geleistet und dadurch die 
> > restlichen Korrekturen wesentlich erleichtert. Vernichtet wurde durch seine 
> > Arbeit zumindest in diesem Gebiet nichts.
> > 
> > Zudem hat er - im Gegensatz zu vielen anderen Mappern -  berücksichtigt, 
> > dass es dort keine Straßennamen gibt und korrekterweise addr:place 
> > verwendet.
> > 
> > Gruß
> > Georg
> > 
> > 
> >  
> > 
> > -Original Message-
> > From: Rudolf Mayer  
> > Sent: Sunday, June 9, 2019 2:41 PM
> > To: talk-at@openstreetmap.org
> > Subject: Re: [Talk-at] minderwertige Importe
> > 
> > Hallo,
> > 
> > ich bin zwar grundsätzlich nicht erfreut, wenn Arbeit zu nichte gemacht 
> > wird, auch nicht die von Johann - aber genauso macht er auch viel Arbeit 
> > von anderen zunichte, bzw. halst den anderen viel Arbeit auf.
> > 
> > Seine Vorgehensweise ist ja wirklich einfach nur arrogant - ich importiere 
> > mal, und als changeset Kommentar bitte ich dann die anderen, die Fehler zu 
> > beseitigen. Das ist einfach nur ignorant.
> > 
> > Auch seine Rechtfertigung, dass man ja jede Adresse dann persönlich 
> > verifizieren müsste zeigt, dass er einfach ein Sofa-Mapper der wirklich 
> > schlechten Art ist (ich habe grundsätzlich keine Abneigung gegen solche, 
> > viele tragen sehr wertvolles bei, wenn aus Satellitenbildern oder von 
> > Mapillary Informationen übertragen werden).
> > 
> > 
> > Grundsätzlich stellt sich mir 

Re: [Talk-at] Hausnummern + Hauseingänge / Adressen in Wien?

[various]

Hallo, 

grundsätzlich Variante 2 (Adresse am Polygon und im Idealfall entry=main-node), 
wenn es nur einen klaren Eingang gibt. Bei großen zusammenhängenden Gebäuden 
mit mehreren Eingängen Variante 3, die Adresse auf den entry=main-node. Oder 
eben bei einem großen Komplex mit einem Eingang (Firma, ...).

Für Couch-Mapping oder unterwegs mal schnell mappen ist meist Variante 2 die 
beste, da man oft am Luftbild nicht genau sagen kann, wo der Eingang jetzt 
wirklich liegt. 

Somit wäre meiner Meinung nach Variante3 eben das Upgrade von Variante2, so zu 
sagen. 

Lg


> dktue  hat am 16. Juni 2019 um 14:15 geschrieben:
> 
> 
> Hallo realadry
> 
> Verzeihung, meine Referenz war falsch, ich meinte, dass ich Variante 2 
> am besten finde. Dann ergibt meine Ausführung auch sinn, dass es eben 
> nicht zu Eckhäusern mit mehreren Eingängen passt, die separate Adressen 
> tragen. In diesem Fall kann Variante 3 helfen, aber: Dann hätten wir 
> zwei verschiedene Verfahren, was die maschinenlesbarkeit verschlechtert.
> 
> Gruß
> dktue
> 
> 
> 
> Am 16.06.2019 um 14:07 schrieb realadry via Talk-at:
> > Hallo dktue,
> >
> > Das Thema gab es vor Jahren schon. Ein Haus (z.B. Eckhaus) kann mehrere
> > Eingänge und dementsprechend Adressen oder Hausnummern haben. Da wäre
> > Variante 3 sogar positiv, da jeder (Haupt)eingang die richtige
> > Adresse(Hausnummer) hat. Nebeneingänge würden dann ohne Adresse nur mit
> > entrance=yes getagged.
> >
> > Wohnanlagen wo mehrere verschiedene Gebäude die selbe Hausnummer haben
> > und nur eine andere Stiegenbezeichnung (die wie eigene Haupteingänge
> > sind) sind wieder ein anderes Thema. Da müsste man entweder jede Stiege
> > als Haupteingang mit der kompletten Adresse eintragen oder eine Relation
> > erstellen.
> >
> > Mir ging es jetzt mal um die innerstädtische Blockrandbebauung oder
> > Einzelhäuser.
> >
> > Lg,
> > realadry
> >
> > Am 16.06.2019 um 13:36 schrieb dktue:
> >> Hallo readadry,
> >>
> >> ich finde auch Variante 3 am besten -- aber wie soll man mit Gebäuden
> >> umgehen, die mehrere Eingänge und mehrere Hausnummern tragen?
> >>
> >> Viele Grüße
> >> dktue
> >>
> >> Am 16.06.2019 um 13:23 schrieb realadry via Talk-at:
> >>> Hallo Leute,
> >>>
> >>> Ich bin zwar schon mehrere Jahre bei OSM aber habe das Thema nicht
> >>> regelmäßig verfolgt, daher weiß ich nicht ob es mittlerweile einen
> >>> Konsens gibt.
> >>>
> >>> Wenn man sich in der Karte in Wien umsieht, sieht man drei verschiedene
> >>> Arten wie Hausnummern gemapped werden:
> >>>
> >>> 1) Eigener Node mit der gesamten Adresse. Gebäude Polygon hat gar keine
> >>> Adressinformation. Dieser Node ist manchmal in der Nähe des
> >>> Hauseinganges, manchmal irgendwo innerhalb der Gebäudes platziert.
> >>>
> >>> 2) Hausnummer und Adresse am Gebäudepolygon. (Eingang als Node des
> >>> Gebäudes.)
> >>>
> >>> 3) Hausnummer, Adresse und Eingang auf einem Node der Teil des Gebäude
> >>> Polygons ist, an der Stelle des Hauseingangs.
> >>>
> >>>
> >>> Variante 1:
> >>> Eine Adresse die "irgendwo" als einzelner Node im Gebäude herumfliegt
> >>> hat keinen Sinn, da man überlicherweise eine Adresse auch mit dem
> >>> Eingang assoziiert (Hausnummer ist ja in Realität fast immer am Eingang
> >>> angebracht). Bei dieser Variante kann weder das Gebäude polygon, noch
> >>> der Hauseingangs-node festgestellt werden. Es wird zum Ratespiel.
> >>>
> >>> Variante 2:
> >>> Hier kann man immerhin den Eingang noch mit der Adresse assozieren, da
> >>> man einfach den "Eingang" node am jeweiligen Gebäude Polygon auslesen
> >>> muss (das man zuvor anhand der Adresse gefunden hat).
> >>>
> >>> Variante 3:
> >>> In jeder Hinsicht die logischste. Eingang, Adresse, Gebäude ist alles
> >>> einfach maschinell auszulesen.
> >>>
> >>> Für das Rendern macht es keinen Unterschied welche Variante gewählt
> >>> wird. Zum Routen und zur maschinellen verarbeitung (Suche) aber sehr
> >>> wohl.
> >>>
> >>> Jetzt fragt ihr euch vielleicht, warum mir das so wichtig ist. Ganz
> >>> einfach. Abgesehen von Routingproblem um den Eingang zu finden. Um
> >>> effizient und maschinell gewisse Bearbeitungen oder Suchen vorzunehmen,
> >>> muss man mit Gewissheit die Adresse eines Gebäudes feststellen können.
> >>>
> >>> z.B. Eine Liste von Adressen von Gebäuden mit gewissen Merkmalen die 
> >>> man
> >>> eintragen möchte oder eine Liste von Adressen von denen man das
> >>> zugehörige Gebäudepolygon markieren/ausgeben möchte.
> >>> Suche ich nach der Adresse, finde aber nur einen Knoten der im nichts
> >>> herumschwebt (wie Variante 1), ist das ein Problem für ein Skript.
> >>>
> >>> Lg,
> >>> realadry
> >>>
> >>> ___
> >>> 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: [Talk-at] minderwertige Importe

[various]

Servus, 

die Sache mit Johann ist die, er macht selten etwas wirklich schlechter, er 
bringt ja durchaus SEHR viele Adressen ein, was auch gut ist und OSM 
weiterbringt.
Er importiert einfach blindlings (früher hatte er behauptet, er importiert 
nicht, deswegen muss er die Import-Regeln nicht beachten), jetzt sagt er zwar, 
dass er importiert, hält sich aber trotzdem nicht an die Import-Regeln. 
Das Hauptproblem ist nicht zwingend, dass er etwas schlechter macht, er macht 
es einfach nur schlecht und damit halst er sich selbst und anderen doppelte 
Arbeit auf. Wenn er das ordentlich vorher besprochen hätte, könnte vieles VIEL 
entspannter ablaufen.
Von seinen Imports sind wohl 80-90% oder so korrekt ausgeführt, Nummern auf den 
Gebäuden und so weiter. Der Rest sind halt Hausnummer enter klar erkennbar auf 
Nebengebäuden oder irgendwo auf Feldern verteilt. Und das ist einfach laufend 
so, darauf hingewiesen kommt halt meist eine patzige Antwort retour und ein 
"Mache ich irgendwann!".

Letztens hat er wohl massenhaft "leere" Nodes gelöscht, da hat er wohl wieder 
einen Filter angesetzt und großzügig gelöscht über große Flächen.

Letzte Sachen grundsätzlich reverten? Nein. In Spezialfällen vielleicht, es 
wurde ja auch schon einiges hinterhergeräumt, behaupte ich mal. Die Sperre? 
Sehr gut, vielleicht kann man ihn so mal dazu zwingen, sich hier und/oder im 
Forum zu melden um das vorher zu diskutieren. 
Wird er das machen? Ich glaube nicht. Er wird die Daten herunterladen, in JOSM 
bearbeiten, warten bis die Sperre abläuft und dann alles hochladen. (sollte 
afaik ja gehen, die Sperre hindert ja nur am hochladen, nicht am runterladen).

Zusätzlich versucht er fleissig Diskussionen auf seinen eigenen externen Blog 
auszulagern, damit er unliebsame Sachen löschen kann.

Und, völlig klar macht er das im glauben, OSM besser zu machen.

Zur Holzhammersache: Nunja, er wurde sehr oft darauf hingewiesen, auch in 
diversen Changesetkommentaren von der DWG, es ist jetzt nicht so die 
Überraschung...
Und Österreichweit treibt er sich schon ziemlich lang herum, nicht erst seit 2 
Wochen.

Lg

> Georg Haefele  hat am 11. Juni 2019 um 11:21 
> geschrieben:
> 
> 
> Hallo,
> 
> also ich finde die Arbeit von Johann sehr wertvoll. Er hat zumindest in 
> meiner Heimatgemeinde in Vorarlberg gute Arbeit geleistet und dadurch die 
> restlichen Korrekturen wesentlich erleichtert. Vernichtet wurde durch seine 
> Arbeit zumindest in diesem Gebiet nichts.
> 
> Zudem hat er - im Gegensatz zu vielen anderen Mappern -  berücksichtigt, dass 
> es dort keine Straßennamen gibt und korrekterweise addr:place verwendet.
> 
> Gruß
> Georg
> 
> 
>  
> 
> -Original Message-
> From: Rudolf Mayer  
> Sent: Sunday, June 9, 2019 2:41 PM
> To: talk-at@openstreetmap.org
> Subject: Re: [Talk-at] minderwertige Importe
> 
> Hallo,
> 
> ich bin zwar grundsätzlich nicht erfreut, wenn Arbeit zu nichte gemacht wird, 
> auch nicht die von Johann - aber genauso macht er auch viel Arbeit von 
> anderen zunichte, bzw. halst den anderen viel Arbeit auf.
> 
> Seine Vorgehensweise ist ja wirklich einfach nur arrogant - ich importiere 
> mal, und als changeset Kommentar bitte ich dann die anderen, die Fehler zu 
> beseitigen. Das ist einfach nur ignorant.
> 
> Auch seine Rechtfertigung, dass man ja jede Adresse dann persönlich 
> verifizieren müsste zeigt, dass er einfach ein Sofa-Mapper der wirklich 
> schlechten Art ist (ich habe grundsätzlich keine Abneigung gegen solche, 
> viele tragen sehr wertvolles bei, wenn aus Satellitenbildern oder von 
> Mapillary Informationen übertragen werden).
> 
> 
> Grundsätzlich stellt sich mir hier nicht nur die Frage wie man die bisherigen 
> Edits behandelt, sondern auch, wie man in Zukunft verhindert, dass er das 
> wieder einfach weiter so macht. Diskussion mit ihm ist ja so ähnlich, wie 
> wenn man mit einer Mauer redet.
> Er sieht sich halt irgendwie als der Missverstandene, und alle anderen in der 
> Community, auch wenn sie geschlossen anderer Meinung sind, liegen einfach 
> falsch. Das passt halt überhaupt nicht zu OSM...
> 
> Eine 7-Tage Sperre wird hier vielleicht nicht viel helfen. Auch hat er ja 
> gezeigt, dass er schnell einfach mal einen neuen account macht (und er hat 
> auch momentan viele die er zugibt, wie man hier sieht: 
> https://www.openstreetmap.org/user/addresshistory*org)
> 
> 
> Alles in allem wäre ich dafür, zumindest einen Teil seiner Edits rückgängig 
> zu machen. Vor allem dort, wo es ja von der lokalen Community nicht gut 
> aufgenommen wurde (das ist imho zumindest in Wien der Fall).
> 
> 
> Lg
> Rudi
> 
> On 08/06/2019 12:03, Frederik Ramm wrote:
> > Hallo,
> > 
> > nach wiederholten Beschwerden über die Importe von addresshistory*org 
> > habe ich hier eine Accountsperre verhängt
> > 
> > https://www.openstreetmap.org/user_blocks/2839
> > 
> > und den User aufgefordert, jeden einzelnen Import vorher an dieser 
> > Stelle hier zu diskutieren, insbesondere was die Datenquelle und die 
> 

Re: [OSM-talk-fr] Osmose erreurs#1270

[ades]

Donc, si je comprends bien, riverbank suffit, il semble d’ailleurs que ce soit 
le cas pour la majorités des fondamenta (sondage rapide sur Osm à Venise). 

Le tag ‘barrier=retaining_wall’ est inadapté, car il ne s’agit pas d’un mur de 
souténement (j’avais pas fait gaffe à la traduction) mais d’un simple mur qui 
sert de garde-corps et qui pourrait donc plutôt être 'taggé barrier=wall’ avec 
indication de sa hauteur ?
 Dans le cas des autres garde-corps ce serait ‘barrier:fence’  ? avec hauteur 
et nature des matériaux (wood, iron,…) ?  j’ai pas trouvé sur le wiki.
> Le 16 juin 2019 à 15:44, lenny.libre  a écrit :
> 
> 
> Le 16/06/2019 à 14:37, osm.sanspourr...@spamgourmet.com 
>  a écrit :
>> De toute évidence garder water=riverbank.
>> 
>> Pour barrier=retaining_wall je suis plus circonspect car un quai est 
>> toujours de facto un mur de retenue. C'est de la tautologie mais ça ne mange 
>> pas de pain. J'aurais plutôt tendance à n'indiquer comme mur de retenue que 
>> ceux qui ne sont que cela.
>> Jean-Yvon
> +1 le barrier=retaining_wall n'est pas correct, en fait ce que le 
> contributeur a voulu représenter c'est un muret garde-corps.
> 
> A Venise les quais (Fondamenta) sont :
> - sans protection comme le "Fondamenta Moro o Coletti" 
> https://www.mapillary.com/map/im/-orxwsNwQjwsP1RDJP0osw 
> , avec de temps en 
> temps des décrochements avec quelque marches qui descendent dans le canal ;
> - avec des garde-corps métalliques comme le "Fondamenta Soranzo delle 
> Fornasa"https://www.mapillary.com/map/im/lb2NUrNFw6VVrRtI9hYOSA 
> 
> - ou des murets garde-corps en pierre ou brique 
> https://www.mapillary.com/map/im/G--V2wPNS767gOY0LbBiSw 
>  similaire à celui 
> de la "Fondamenta del Vin" ; le garde-corps de la collection Peggy Guggenheim 
> (https://www.mapillary.com/map/im/gVd82Nx1etHQMD4Fgf-I3g 
> ) a aussi été tagué 
> comme mur de soutènement 
> Leni
>> 
>> Le 15/06/2019 à 14:58, ades - ades.s...@orange.fr 
>>  a écrit :
>>> Eau de mer pas trop, eau vénitienne oui, avec un ‘tipo’, yeux plein de 
>>> merde certainement…
>>> 
>>> Désolé je n’avais pas bien regardé, sans doute l’heure, faut bien trouver 
>>> une excuse ;-) .
>>> 
>>> Il me semble néanmoins que vue de la  rue c’est une impasse, mais 
>>> effectivement bornée par un quai (élément linéaire possible dans osm ?).
>>> 
>>> Maintenant, je viens de jeter un coup d’oeil sur Venise dans josm, ce genre 
>>> d'endroit semble principalement décrit par une rue qui s’achève un peu 
>>> avant le canal, qui n’est décrit que par ‘riverbank’. 
>>> Pas de mention de quai, mais ‘barrier:retaining_wall', dans le cas d'une 
>>> voie longeant un canal (Fondamenta del Vin par exemple).
>>> 
>>> Combiner ‘barrier:retaining_wall’ ou ‘water:riverbank’ avec ‘man_made:quay’ 
>>> ?
>>> 
 Le 15 juin 2019 à 10:13, osm.sanspourr...@spamgourmet.com 
  a écrit :
 
 Marin d'eau de mer, va ! ^^
 
 Si tu regarde à côté tu vois que les bateaux ne s'amarrent pas qu'avec des 
 anneaux et des bites mais avec des pieux et il y a bien un tel poteau de 
 bois juste à droite sur la photo.
 
 De plus si tu regardes depuis la route tu vois deux anneaux.
 
 CQFD.
 Jean-Yvon
 Le 14/06/2019 à 22:16, ades - ades.s...@orange.fr 
  a écrit :
> faudrait d’abord demander aux Vénitiens comment ils appellent ça ;-)
> 
> Je ne taguerai pas ça comme quai, où sont les éléments constitutifs d’un 
> quai : anneaux, bites, etc. ? Et je pense que même si ça peut servir de 
> point d’embarquement ce n’est pas un quai.
> 
> Là on a juste la fin d’une rue. Que ce soit un mur ou un canal qui 
> termine la rue, c’est la même chose, la rue s’arrête là, point… c’est une 
> impasse.
> 
> 
>> Le 14 juin 2019 à 21:40, osm.sanspourr...@spamgourmet.com 
>>  a écrit :
>> 
>> Vu l'usage et l'absence de parapet/barrière je n'hésiterais pas : c'est 
>> un quai.
>> 
>> C'est fait pour servir de quai et non pour éviter que la rue ne tombe ^^
>> 
>> Le 14/06/2019 à 09:58, marc marc - marc_marc_...@hotmail.com 
>>  a écrit :
>>> Le 14.06.19 à 08:39, lenny.libre a écrit :
 j'hésite encore entre le noexit et le "man_made=quay"
 https://goo.gl/maps/ezwLyzp122JTQD2U9 
 
>>> j'opterais pour un quai ou un mur de soutènement
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org 

Re: [OSM-talk-fr] Osmose erreurs#1270

[lenny.libre]

Le 16/06/2019 à 14:37, osm.sanspourr...@spamgourmet.com a écrit :


De toute évidence garder water=riverbank.

Pour barrier=retaining_wall je suis plus circonspect car un quai est 
toujours de facto un mur de retenue. C'est de la tautologie mais ça ne 
mange pas de pain. J'aurais plutôt tendance à n'indiquer comme mur de 
retenue que ceux qui ne sont que cela.


Jean-Yvon

+1 le barrier=retaining_wall n'est pas correct, en fait ce que le 
contributeur a voulu représenter c'est un muret garde-corps.


A Venise les quais (Fondamenta) sont :
- sans protection comme le "Fondamenta Moro o Coletti" 
https://www.mapillary.com/map/im/-orxwsNwQjwsP1RDJP0osw, avec de temps 
en temps des décrochements avec quelque marches qui descendent dans le 
canal ;
- avec des garde-corps métalliques comme le "Fondamenta Soranzo delle 
Fornasa" https://www.mapillary.com/map/im/lb2NUrNFw6VVrRtI9hYOSA
- ou des murets garde-corps en pierre ou brique 
https://www.mapillary.com/map/im/G--V2wPNS767gOY0LbBiSw similaire à 
celui de la "Fondamenta del Vin" ; le garde-corps de la collection Peggy 
Guggenheim (https://www.mapillary.com/map/im/gVd82Nx1etHQMD4Fgf-I3g) a 
aussi été tagué comme mur de soutènement


Leni


Le 15/06/2019 à 14:58, ades - ades.s...@orange.fr a écrit :
Eau de mer pas trop, eau vénitienne oui, avec un ‘tipo’, yeux plein 
de merde certainement…


Désolé je n’avais pas bien regardé, sans doute l’heure, faut bien 
trouver une excuse ;-) .


Il me semble néanmoins que vue de la  rue c’est une impasse, mais 
effectivement bornée par un quai (élément linéaire possible dans osm ?).


Maintenant, je viens de jeter un coup d’oeil sur Venise dans josm, ce 
genre d'endroit semble principalement décrit par une rue qui s’achève 
un peu avant le canal, qui n’est décrit que par ‘riverbank’.
Pas de mention de quai, mais ‘barrier:retaining_wall', dans le cas 
d'une voie longeant un canal (Fondamenta del Vin par exemple).


Combiner ‘barrier:retaining_wall’ ou ‘water:riverbank’ avec 
‘man_made:quay’ ?


Le 15 juin 2019 à 10:13, osm.sanspourr...@spamgourmet.com 
 a écrit :


Marin d'eau de mer, va ! ^^

Si tu regarde à côté tu vois que les bateaux ne s'amarrent pas 
qu'avec des anneaux et des bites mais avec des pieux et il y a bien 
un tel poteau de bois juste à droite sur la photo.


De plus si tu regardes depuis la route tu vois deux anneaux.

CQFD.

Jean-Yvon

Le 14/06/2019 à 22:16, ades - ades.s...@orange.fr a écrit :

faudrait d’abord demander aux Vénitiens comment ils appellent ça ;-)

Je ne taguerai pas ça comme quai, où sont les éléments constitutifs 
d’un quai : anneaux, bites, etc. ? Et je pense que même si ça peut 
servir de point d’embarquement ce n’est pas un quai.


Là on a juste la fin d’une rue. Que ce soit un mur ou un canal qui 
termine la rue, c’est la même chose, la rue s’arrête là, point… 
c’est une impasse.



Le 14 juin 2019 à 21:40, osm.sanspourr...@spamgourmet.com 
 a écrit :


Vu l'usage et l'absence de parapet/barrière je n'hésiterais pas : 
c'est un quai.


C'est fait pour servir de quai et non pour éviter que la rue ne 
tombe ^^


Le 14/06/2019 à 09:58, marc marc - marc_marc_...@hotmail.com a écrit :

Le 14.06.19 à 08:39, lenny.libre a écrit :

j'hésite encore entre le noexit et le "man_made=quay"
https://goo.gl/maps/ezwLyzp122JTQD2U9

j'opterais pour un quai ou un mur de soutènement
___
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




___
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




___
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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-cz] Body záchrany Lesy ČR

[Pavel Machek via talk-cz]

On Sat 2019-06-01 14:34:56, Spratek wrote:
> Zdravím, 
> co se týče smlouvy, Lesy ČR obávají zneužití nějakým komerčním subjektem, 
> proto tam je klausule o odvolání souhlasu.
> Pokud by se například stalo, že OSM pohltí nějaký nadnárodní konglomerát 
> (stejně jako se to stalo v případě OpenOffice nebo Skype ).
> Smlouva je psaná na mě, pokud potřebuje někdo mé iniciály kvůli lepšímu 
> spánku, můžu je poskytnout.
> 
> Ano odvolání souhlasu může nastat, v tom případě se podá nová žádost, není 
> přece možné, aby veřejnou službu financovanou z veřejných peněz odmítli 
> zpřístupnit veřejnosti.
> S tím bych se nesmířil, i kdyby banda právníku tvrdila opak.
> 

Ano, mame zakon o svobodnem pristupu k informacim, ktery by mel zarucovat, ze 
verejne
veci budou verejne.

Pres ten zakon by bylo mozne sehnat "spravny" souhlas. Jenze to se zatim 
nestalo, a osm
je opatrna.


Pavel

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

Re: [OSM-talk-fr] Osmose erreurs#1270

[osm . sanspourriel]

De toute évidence garder water=riverbank.

Pour barrier=retaining_wall je suis plus circonspect car un quai est
toujours de facto un mur de retenue. C'est de la tautologie mais ça ne
mange pas de pain. J'aurais plutôt tendance à n'indiquer comme mur de
retenue que ceux qui ne sont que cela.

Jean-Yvon

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

Eau de mer pas trop, eau vénitienne oui, avec un ‘tipo’, yeux plein de
merde certainement…

Désolé je n’avais pas bien regardé, sans doute l’heure, faut bien
trouver une excuse ;-) .

Il me semble néanmoins que vue de la  rue c’est une impasse, mais
effectivement bornée par un quai (élément linéaire possible dans osm ?).

Maintenant, je viens de jeter un coup d’oeil sur Venise dans josm, ce
genre d'endroit semble principalement décrit par une rue qui s’achève
un peu avant le canal, qui n’est décrit que par ‘riverbank’.
Pas de mention de quai, mais ‘barrier:retaining_wall', dans le cas
d'une voie longeant un canal (Fondamenta del Vin par exemple).

Combiner ‘barrier:retaining_wall’ ou ‘water:riverbank’ avec
‘man_made:quay’ ?


Le 15 juin 2019 à 10:13, osm.sanspourr...@spamgourmet.com
 a écrit :

Marin d'eau de mer, va ! ^^

Si tu regarde à côté tu vois que les bateaux ne s'amarrent pas
qu'avec des anneaux et des bites mais avec des pieux et il y a bien
un tel poteau de bois juste à droite sur la photo.

De plus si tu regardes depuis la route tu vois deux anneaux.

CQFD.

Jean-Yvon

Le 14/06/2019 à 22:16, ades - ades.s...@orange.fr a écrit :

faudrait d’abord demander aux Vénitiens comment ils appellent ça ;-)

Je ne taguerai pas ça comme quai, où sont les éléments constitutifs
d’un quai : anneaux, bites, etc. ? Et je pense que même si ça peut
servir de point d’embarquement ce n’est pas un quai.

Là on a juste la fin d’une rue. Que ce soit un mur ou un canal qui
termine la rue, c’est la même chose, la rue s’arrête là, point…
c’est une impasse.



Le 14 juin 2019 à 21:40, osm.sanspourr...@spamgourmet.com
 a écrit :

Vu l'usage et l'absence de parapet/barrière je n'hésiterais pas :
c'est un quai.

C'est fait pour servir de quai et non pour éviter que la rue ne
tombe ^^

Le 14/06/2019 à 09:58, marc marc - marc_marc_...@hotmail.com a écrit :

Le 14.06.19 à 08:39, lenny.libre a écrit :

j'hésite encore entre le noexit et le "man_made=quay"
https://goo.gl/maps/ezwLyzp122JTQD2U9

j'opterais pour un quai ou un mur de soutènement
___
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




___
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




___
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-at] Hausnummern + Hauseingänge / Adressen in Wien?

[dktue]

Hallo realadry

Verzeihung, meine Referenz war falsch, ich meinte, dass ich Variante 2 
am besten finde. Dann ergibt meine Ausführung auch sinn, dass es eben 
nicht zu Eckhäusern mit mehreren Eingängen passt, die separate Adressen 
tragen. In diesem Fall kann Variante 3 helfen, aber: Dann hätten wir 
zwei verschiedene Verfahren, was die maschinenlesbarkeit verschlechtert.


Gruß
dktue



Am 16.06.2019 um 14:07 schrieb realadry via Talk-at:

Hallo dktue,

Das Thema gab es vor Jahren schon. Ein Haus (z.B. Eckhaus) kann mehrere
Eingänge und dementsprechend Adressen oder Hausnummern haben. Da wäre
Variante 3 sogar positiv, da jeder (Haupt)eingang die richtige
Adresse(Hausnummer) hat. Nebeneingänge würden dann ohne Adresse nur mit
entrance=yes getagged.

Wohnanlagen wo mehrere verschiedene Gebäude die selbe Hausnummer haben
und nur eine andere Stiegenbezeichnung (die wie eigene Haupteingänge
sind) sind wieder ein anderes Thema. Da müsste man entweder jede Stiege
als Haupteingang mit der kompletten Adresse eintragen oder eine Relation
erstellen.

Mir ging es jetzt mal um die innerstädtische Blockrandbebauung oder
Einzelhäuser.

Lg,
realadry

Am 16.06.2019 um 13:36 schrieb dktue:

Hallo readadry,

ich finde auch Variante 3 am besten -- aber wie soll man mit Gebäuden
umgehen, die mehrere Eingänge und mehrere Hausnummern tragen?

Viele Grüße
dktue

Am 16.06.2019 um 13:23 schrieb realadry via Talk-at:

Hallo Leute,

Ich bin zwar schon mehrere Jahre bei OSM aber habe das Thema nicht
regelmäßig verfolgt, daher weiß ich nicht ob es mittlerweile einen
Konsens gibt.

Wenn man sich in der Karte in Wien umsieht, sieht man drei verschiedene
Arten wie Hausnummern gemapped werden:

1) Eigener Node mit der gesamten Adresse. Gebäude Polygon hat gar keine
Adressinformation. Dieser Node ist manchmal in der Nähe des
Hauseinganges, manchmal irgendwo innerhalb der Gebäudes platziert.

2) Hausnummer und Adresse am Gebäudepolygon. (Eingang als Node des
Gebäudes.)

3) Hausnummer, Adresse und Eingang auf einem Node der Teil des Gebäude
Polygons ist, an der Stelle des Hauseingangs.


Variante 1:
Eine Adresse die "irgendwo" als einzelner Node im Gebäude herumfliegt
hat keinen Sinn, da man überlicherweise eine Adresse auch mit dem
Eingang assoziiert (Hausnummer ist ja in Realität fast immer am Eingang
angebracht). Bei dieser Variante kann weder das Gebäude polygon, noch
der Hauseingangs-node festgestellt werden. Es wird zum Ratespiel.

Variante 2:
Hier kann man immerhin den Eingang noch mit der Adresse assozieren, da
man einfach den "Eingang" node am jeweiligen Gebäude Polygon auslesen
muss (das man zuvor anhand der Adresse gefunden hat).

Variante 3:
In jeder Hinsicht die logischste. Eingang, Adresse, Gebäude ist alles
einfach maschinell auszulesen.

Für das Rendern macht es keinen Unterschied welche Variante gewählt
wird. Zum Routen und zur maschinellen verarbeitung (Suche) aber sehr
wohl.

Jetzt fragt ihr euch vielleicht, warum mir das so wichtig ist. Ganz
einfach. Abgesehen von Routingproblem um den Eingang zu finden. Um
effizient und maschinell gewisse Bearbeitungen oder Suchen vorzunehmen,
muss man mit Gewissheit die Adresse eines Gebäudes feststellen können.

z.B. Eine Liste von Adressen von Gebäuden mit gewissen Merkmalen die 
man

eintragen möchte oder eine Liste von Adressen von denen man das
zugehörige Gebäudepolygon markieren/ausgeben möchte.
Suche ich nach der Adresse, finde aber nur einen Knoten der im nichts
herumschwebt (wie Variante 1), ist das ein Problem für ein Skript.

Lg,
realadry

___
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


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

[ades]

En résumant, j’ai cru comprendre que la clé principale pourrait -être:  
‘amenity: restaurant’ ; la secondaire ’restaurant=takeaway’, la « tertiaire » 
‘takeaway:only’.
cette combinaison semble bien répondre à ta question de départ :"Comment 
peut-on taguer un commerce qui ne vend que des plats à emporter"

Le wiki prévoit le cas dont tu parles : "Si le restaurant propose sur place ou 
à emporter : utilisez le tag takeaway 
=yes/no/only . « 

Pour ma part je comprend que ‘restaurant’ est un terme générique indiquant un 
lieu où l’on prépare et vend à manger ;
‘takeaway' serait un terme  spécifique indiquant la possibilité d’emporter, 
'takeaway: only', un autre spécifique répondant à ta question..

Pour ce qui est d’un traiteur, Pour ma pomme, en français, et habituellement, 
un traiteur ne fabrique pas des plats à emporter, mais livre un ensemble de 
plats constituant un repas complet, voire un buffet, de l’apero au digestif… et 
‘caterer’ semble effectivement correspondre.


> Le 16 juin 2019 à 12:25, Muselaar  a écrit :
> 
> 
> Le 16/06/2019 à 00:49, marc marc a écrit :
>> Le 16.06.19 à 00:27, Muselaar a écrit :
>>> Le 15/06/2019 à 19:57, marc marc a écrit :
 Le 15.06.19 à 19:43, Julien Lepiller a écrit :
> Le 15 juin 2019 19:31:36 GMT+02:00, Muselaar  a
> écrit :
>> Ça devrait plutôt être shop=caterer
 craft : lieu de fabrication
 shop : lieu de vente
 parfois les 2 dans un même lieu, parfois pas
> takeway=only ?
>>> page correspondante : https://wiki.openstreetmap.org/wiki/FR:Key:takeaway
>>> 
>>> c'est une clé additionnelle,
>>> il faut que je qualifie à la base le commerce.
>> de ce que tu dis : shop=caterer takeaway=only
>> cela décrit le lieu de vente des plats à emporter d'un traiteur
> Mais, en fait, si l'on considère qu'un restaurant peut uniquement proposer 
> des plats à emporter, quelle est la différence entre un traiteur et un 
> restaurant, et un tel établissement peut-il décemment être appelé restaurant ?
> 
> ___
> 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-at] Hausnummern + Hauseingänge / Adressen in Wien?

[realadry via Talk-at]

Hallo dktue,

Das Thema gab es vor Jahren schon. Ein Haus (z.B. Eckhaus) kann mehrere
Eingänge und dementsprechend Adressen oder Hausnummern haben. Da wäre
Variante 3 sogar positiv, da jeder (Haupt)eingang die richtige
Adresse(Hausnummer) hat. Nebeneingänge würden dann ohne Adresse nur mit
entrance=yes getagged.

Wohnanlagen wo mehrere verschiedene Gebäude die selbe Hausnummer haben
und nur eine andere Stiegenbezeichnung (die wie eigene Haupteingänge
sind) sind wieder ein anderes Thema. Da müsste man entweder jede Stiege
als Haupteingang mit der kompletten Adresse eintragen oder eine Relation
erstellen.

Mir ging es jetzt mal um die innerstädtische Blockrandbebauung oder
Einzelhäuser.

Lg,
realadry

Am 16.06.2019 um 13:36 schrieb dktue:

Hallo readadry,

ich finde auch Variante 3 am besten -- aber wie soll man mit Gebäuden
umgehen, die mehrere Eingänge und mehrere Hausnummern tragen?

Viele Grüße
dktue

Am 16.06.2019 um 13:23 schrieb realadry via Talk-at:

Hallo Leute,

Ich bin zwar schon mehrere Jahre bei OSM aber habe das Thema nicht
regelmäßig verfolgt, daher weiß ich nicht ob es mittlerweile einen
Konsens gibt.

Wenn man sich in der Karte in Wien umsieht, sieht man drei verschiedene
Arten wie Hausnummern gemapped werden:

1) Eigener Node mit der gesamten Adresse. Gebäude Polygon hat gar keine
Adressinformation. Dieser Node ist manchmal in der Nähe des
Hauseinganges, manchmal irgendwo innerhalb der Gebäudes platziert.

2) Hausnummer und Adresse am Gebäudepolygon. (Eingang als Node des
Gebäudes.)

3) Hausnummer, Adresse und Eingang auf einem Node der Teil des Gebäude
Polygons ist, an der Stelle des Hauseingangs.


Variante 1:
Eine Adresse die "irgendwo" als einzelner Node im Gebäude herumfliegt
hat keinen Sinn, da man überlicherweise eine Adresse auch mit dem
Eingang assoziiert (Hausnummer ist ja in Realität fast immer am Eingang
angebracht). Bei dieser Variante kann weder das Gebäude polygon, noch
der Hauseingangs-node festgestellt werden. Es wird zum Ratespiel.

Variante 2:
Hier kann man immerhin den Eingang noch mit der Adresse assozieren, da
man einfach den "Eingang" node am jeweiligen Gebäude Polygon auslesen
muss (das man zuvor anhand der Adresse gefunden hat).

Variante 3:
In jeder Hinsicht die logischste. Eingang, Adresse, Gebäude ist alles
einfach maschinell auszulesen.

Für das Rendern macht es keinen Unterschied welche Variante gewählt
wird. Zum Routen und zur maschinellen verarbeitung (Suche) aber sehr
wohl.

Jetzt fragt ihr euch vielleicht, warum mir das so wichtig ist. Ganz
einfach. Abgesehen von Routingproblem um den Eingang zu finden. Um
effizient und maschinell gewisse Bearbeitungen oder Suchen vorzunehmen,
muss man mit Gewissheit die Adresse eines Gebäudes feststellen können.

z.B. Eine Liste von Adressen von Gebäuden mit gewissen Merkmalen die man
eintragen möchte oder eine Liste von Adressen von denen man das
zugehörige Gebäudepolygon markieren/ausgeben möchte.
Suche ich nach der Adresse, finde aber nur einen Knoten der im nichts
herumschwebt (wie Variante 1), ist das ein Problem für ein Skript.

Lg,
realadry

___
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


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

Re: [Talk-at] Hausnummern + Hauseingänge / Adressen in Wien?

[dktue]

Hallo readadry,

ich finde auch Variante 3 am besten -- aber wie soll man mit Gebäuden 
umgehen, die mehrere Eingänge und mehrere Hausnummern tragen?


Viele Grüße
dktue

Am 16.06.2019 um 13:23 schrieb realadry via Talk-at:

Hallo Leute,

Ich bin zwar schon mehrere Jahre bei OSM aber habe das Thema nicht
regelmäßig verfolgt, daher weiß ich nicht ob es mittlerweile einen
Konsens gibt.

Wenn man sich in der Karte in Wien umsieht, sieht man drei verschiedene
Arten wie Hausnummern gemapped werden:

1) Eigener Node mit der gesamten Adresse. Gebäude Polygon hat gar keine
Adressinformation. Dieser Node ist manchmal in der Nähe des
Hauseinganges, manchmal irgendwo innerhalb der Gebäudes platziert.

2) Hausnummer und Adresse am Gebäudepolygon. (Eingang als Node des
Gebäudes.)

3) Hausnummer, Adresse und Eingang auf einem Node der Teil des Gebäude
Polygons ist, an der Stelle des Hauseingangs.


Variante 1:
Eine Adresse die "irgendwo" als einzelner Node im Gebäude herumfliegt
hat keinen Sinn, da man überlicherweise eine Adresse auch mit dem
Eingang assoziiert (Hausnummer ist ja in Realität fast immer am Eingang
angebracht). Bei dieser Variante kann weder das Gebäude polygon, noch
der Hauseingangs-node festgestellt werden. Es wird zum Ratespiel.

Variante 2:
Hier kann man immerhin den Eingang noch mit der Adresse assozieren, da
man einfach den "Eingang" node am jeweiligen Gebäude Polygon auslesen
muss (das man zuvor anhand der Adresse gefunden hat).

Variante 3:
In jeder Hinsicht die logischste. Eingang, Adresse, Gebäude ist alles
einfach maschinell auszulesen.

Für das Rendern macht es keinen Unterschied welche Variante gewählt
wird. Zum Routen und zur maschinellen verarbeitung (Suche) aber sehr 
wohl.


Jetzt fragt ihr euch vielleicht, warum mir das so wichtig ist. Ganz
einfach. Abgesehen von Routingproblem um den Eingang zu finden. Um
effizient und maschinell gewisse Bearbeitungen oder Suchen vorzunehmen,
muss man mit Gewissheit die Adresse eines Gebäudes feststellen können.

z.B. Eine Liste von Adressen von Gebäuden mit gewissen Merkmalen die man
eintragen möchte oder eine Liste von Adressen von denen man das
zugehörige Gebäudepolygon markieren/ausgeben möchte.
Suche ich nach der Adresse, finde aber nur einen Knoten der im nichts
herumschwebt (wie Variante 1), ist das ein Problem für ein Skript.

Lg,
realadry

___
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: [talk-au] Fwd: Currently, OSM is rendering water throughout the suburbs of Perth

[Warin]

OSMInspector reports some problem with the Tasman Sea relation - far too big on 
my computer to reasonably check...:-\


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

[Talk-at] Hausnummern + Hauseingänge / Adressen in Wien?

[realadry via Talk-at]

Hallo Leute,

Ich bin zwar schon mehrere Jahre bei OSM aber habe das Thema nicht
regelmäßig verfolgt, daher weiß ich nicht ob es mittlerweile einen
Konsens gibt.

Wenn man sich in der Karte in Wien umsieht, sieht man drei verschiedene
Arten wie Hausnummern gemapped werden:

1) Eigener Node mit der gesamten Adresse. Gebäude Polygon hat gar keine
Adressinformation. Dieser Node ist manchmal in der Nähe des
Hauseinganges, manchmal irgendwo innerhalb der Gebäudes platziert.

2) Hausnummer und Adresse am Gebäudepolygon. (Eingang als Node des
Gebäudes.)

3) Hausnummer, Adresse und Eingang auf einem Node der Teil des Gebäude
Polygons ist, an der Stelle des Hauseingangs.


Variante 1:
Eine Adresse die "irgendwo" als einzelner Node im Gebäude herumfliegt
hat keinen Sinn, da man überlicherweise eine Adresse auch mit dem
Eingang assoziiert (Hausnummer ist ja in Realität fast immer am Eingang
angebracht). Bei dieser Variante kann weder das Gebäude polygon, noch
der Hauseingangs-node festgestellt werden. Es wird zum Ratespiel.

Variante 2:
Hier kann man immerhin den Eingang noch mit der Adresse assozieren, da
man einfach den "Eingang" node am jeweiligen Gebäude Polygon auslesen
muss (das man zuvor anhand der Adresse gefunden hat).

Variante 3:
In jeder Hinsicht die logischste. Eingang, Adresse, Gebäude ist alles
einfach maschinell auszulesen.

Für das Rendern macht es keinen Unterschied welche Variante gewählt
wird. Zum Routen und zur maschinellen verarbeitung (Suche) aber sehr wohl.

Jetzt fragt ihr euch vielleicht, warum mir das so wichtig ist. Ganz
einfach. Abgesehen von Routingproblem um den Eingang zu finden. Um
effizient und maschinell gewisse Bearbeitungen oder Suchen vorzunehmen,
muss man mit Gewissheit die Adresse eines Gebäudes feststellen können.

z.B. Eine Liste von Adressen von Gebäuden mit gewissen Merkmalen die man
eintragen möchte oder eine Liste von Adressen von denen man das
zugehörige Gebäudepolygon markieren/ausgeben möchte.
Suche ich nach der Adresse, finde aber nur einen Knoten der im nichts
herumschwebt (wie Variante 1), ist das ein Problem für ein Skript.

Lg,
realadry

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

Re: [talk-au] Fwd: Currently, OSM is rendering water throughout the suburbs of Perth

[Mateusz Konieczny]

It happens regularly in many places across the world. It is a data issue,
especially as rendering bug would become visible after map style update.


16 Jun 2019, 12:02 by ewen.h...@gmail.com:

> Hi, 
>   Has anyone else noticed that the great flood of 2019 is on us. I can't find 
> the issue so is it a mapping issue or a rendering issue please as I cannot 
> find the source? See > 
> https://www.openstreetmap.org/#map=13/-32.2436/115.9987 
> >  
> -- 
>
>
>
>

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

Re: [OSM-talk-fr] Traiteur

[Muselaar]

Le 16/06/2019 à 00:49, marc marc a écrit :

Le 16.06.19 à 00:27, Muselaar a écrit :

Le 15/06/2019 à 19:57, marc marc a écrit :

Le 15.06.19 à 19:43, Julien Lepiller a écrit :

Le 15 juin 2019 19:31:36 GMT+02:00, Muselaar  a
écrit :

Ça devrait plutôt être shop=caterer

craft : lieu de fabrication
shop : lieu de vente
parfois les 2 dans un même lieu, parfois pas

takeway=only ?

page correspondante : https://wiki.openstreetmap.org/wiki/FR:Key:takeaway

c'est une clé additionnelle,
il faut que je qualifie à la base le commerce.

de ce que tu dis : shop=caterer takeaway=only
cela décrit le lieu de vente des plats à emporter d'un traiteur
Mais, en fait, si l'on considère qu'un restaurant peut uniquement 
proposer des plats à emporter, quelle est la différence entre un 
traiteur et un restaurant, et un tel établissement peut-il décemment 
être appelé restaurant ?


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

[Talk-us] weeklyOSM #464 2019-06-04-2019-06-10

[weeklyteam]

The weekly round-up of OSM news, issue # 464,
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/12177/

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-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[talk-au] Fwd: Currently, OSM is rendering water throughout the suburbs of Perth

[Ewen Hill]

Hi,
  Has anyone else noticed that the great flood of 2019 is on us. I can't
find the issue so is it a mapping issue or a rendering issue please as I
cannot find the source? See
https://www.openstreetmap.org/#map=13/-32.2436/115.9987
-- 
[image: image.png]
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[Talk-GB] weeklyOSM #464 2019-06-04-2019-06-10

[weeklyteam]

The weekly round-up of OSM news, issue # 464,
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/12177/

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-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-in] weeklyOSM #464 2019-06-04-2019-06-10

[weeklyteam]

The weekly round-up of OSM news, issue # 464,
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/12177/

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-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[OSM-talk-ie] weeklyOSM #464 2019-06-04-2019-06-10

[weeklyteam]

The weekly round-up of OSM news, issue # 464,
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/12177/

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-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

[talk-ph] weeklyOSM #464 2019-06-04-2019-06-10

[weeklyteam]

The weekly round-up of OSM news, issue # 464,
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/12177/

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-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[Talk-ca] weeklyOSM #464 2019-06-04-2019-06-10

[weeklyteam]

The weekly round-up of OSM news, issue # 464,
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/12177/

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

[OSM-talk] weeklyOSM #464 2019-06-04-2019-06-10

[weeklyteam]

The weekly round-up of OSM news, issue # 464,
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/12177/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-africa] weeklyOSM #464 2019-06-04-2019-06-10

[weeklyteam]

The weekly round-up of OSM news, issue # 464,
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/12177/

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-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

[OSM-talk-fr] Indoor Mapping par une collectivité territoriale

[Axel Listes]

Bonjour,

Mon pseudo vous est probablement pas familier, je suis contributeur
d'OSM depuis plusieurs années, principalement sur le thème vélo.

Cette fois ça concerne la cartographie d'intérieurs.
Je travaille pour une collectivité territoriale dans le Grand Est,
celle-ci a lancé un projet de cartographie d'intérieurs des bâtiments
publics, plus spécifiquement les parties accessibles au public. L'idée
étant de mettre à disposition des habitants des bornes interactives sur
le territoire de la collectivité.

La ville en question a décidé de mettre en avant la culture du libre,
licences libres, formats ouverts, standards ... pour une approche
communautaire des outils numériques, lutter notamment contre le simple
consumérisme, les verrouillages, garder le contrôle sur les données.
Dans cette logique, le projet se tourne vers l'usage d'OSM.

Je suis en charge de ce projet, ma fonction consistant à créer la
liaison entre le service numérique de la ville et ses administrés,
l’intérêt pour l'Indoor Mapping est de faire participer la vie locale au
projet.

J'ai lancé deux animations ces derniers jours pour présenter le projet
et commencer à représenter un bâtiment qui sert de prototype (le
bâtiment ou je travaille).
Celles-ci n'ont pas attirées les foules, mais elles ont permis
d'enclencher le projet et donc d'anticiper la réutilisation des plans
des bâtiments avec la philosophie de la culture libre qui va avec.

Une documentation a été créé ayant pour but de donner les grandes lignes
sur comment mettre à disposition des plans pour permettre l'indoor
mapping via OSM. Celle-ci étant sous licence libre, elle est améliorable.
https://fccl-vandoeuvre.fr/culture/items/show/40
Je viens de la copier dans le wiki OSM
https://wiki.openstreetmap.org/wiki/FR:Importing_Plans_For_Indoor_Mapping ,
il me reste juste à téléverser les fichiers images que j'ai oublié de
copier depuis le poste du boulot ! Ce sera fait dans quelques jours.

En ce qui concerne le projet de cartographie locale, ces animations ont
pu me permettre d'avoir de la visibilité et de créer un contact avec des
architectes qui travaillent actuellement sur le BIM et qui considèrent
que cette approche Indoor Mapping est intéressante car complémentaire.
Il y a aussi une université locale ou les étudiants ont tendances à se
perdre en début d'années dans leurs immenses locaux. Il y a donc du
potentiel, à suivre ...

Axel.

-- 

L’intégralité de ce courrier électronique est exclusivement réservé à
l'usage des personnes auxquelles il est destiné. L’auteur ne donne pas
autorisation pour une quelconque autre exploitation de données,
notamment à des fins de statistiques et de surveillance.

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