Il 13/11/19 18:23, Francesco Ansanelli ha scritto:
> Grazie per la segnalazione, Martin!!
> Condivido ogni parola e sono convitto che Frédéric, che ho avuto la fortuna
> di conoscere, sia un ottimo candidato per cambiare le sorti di iD.
>
> Francesco
>
Concordo sulla lettera, anche se un anno
Il giorno mer, 13/11/2019 alle 20.42 +0100, Martin Koppenhoefer ha
scritto:
>
> Scusate, tanto testo ;-)
>
> Che dite, vogliamo appoggiare l'idea? Attualmente è ancora molto
> "fresco" (da modificare, è la prima bozza), ma la direzione sarà
> probabilmente quella, attualmente c'è la
grazie Martin di averci portato a conoscenza dell'iniziativa in corso nella
comunità tedesca.
Spero che la facciano diventare una pagina wiki sottoposta a votazione,
così da tutto il mondo possiamo sottoscrivere e commentare.
Il giorno mer 13 nov 2019 alle ore 20:43 Martin Koppenhoefer <
On Wed, Nov 13, 2019 at 8:43 PM Martin Koppenhoefer
wrote:
>
> Che dite, vogliamo appoggiare l'idea? Attualmente è ancora molto "fresco" (da
> modificare, è la prima bozza), ma la direzione sarà probabilmente quella,
> attualmente c'è la discussione in talk-de e forum.
Grazie Martin per questa
Ciao Martin,
grazie della segnalazione.
mi sono letto tutti gli interventi del post di Poole e quoto appieno quanto
scrive.
Leggere quanto espresso da questo Bryan è uno schiaffo in faccia all'idea
stessa di OSM e alle regole che la comunità si è data.
Decidere poi unilateralmente come si mappa
On Wed, 13 Nov 2019 at 20:43, Martin Koppenhoefer
wrote:
>
>
> Scusate, tanto testo ;-)
>
> Che dite, vogliamo appoggiare l'idea? Attualmente è ancora molto "fresco" (da
> modificare, è la prima bozza), ma la direzione sarà probabilmente quella,
> attualmente c'è la discussione in talk-de e
Am Mi., 13. Nov. 2019 um 16:10 Uhr schrieb Stefano :
> Non è nello spirito di un progetto open di ignorare e azittare le
> critiche, al meno non lo è quando sei lo sviluppatore dell'unico editore
> sulla pagina principale. E tanto di più quando non fai quello che vuoi tu,
> ma quello che voglione
Grazie per la segnalazione, Martin!!
Condivido ogni parola e sono convitto che Frédéric, che ho avuto la fortuna
di conoscere, sia un ottimo candidato per cambiare le sorti di iD.
Francesco
Il mer 13 nov 2019, 15:11 Martin Koppenhoefer ha
scritto:
> Vi segnalo questo diario post, che tratta di
Il giorno mer 13 nov 2019 alle ore 15:46 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:
> Am Mi., 13. Nov. 2019 um 15:23 Uhr schrieb Stefano :
>
>> L'unica cosa che posso dire è:
>> This is why we can't have nice things.
>>
>
>
> puoi tranquillamente avere "nice things", ma non c'è
Am Mi., 13. Nov. 2019 um 15:23 Uhr schrieb Stefano :
> L'unica cosa che posso dire è:
> This is why we can't have nice things.
>
puoi tranquillamente avere "nice things", ma non c'è bisogno che
constringiamo tutti a portarsi il cavallo di troia in casa, so perché Josm
è troppo complicato o
Il giorno mer 13 nov 2019 alle ore 15:11 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:
> Vi segnalo questo diario post, che tratta di iD editor:
>
> https://www.openstreetmap.org/user/woodpeck/diary/391175
>
L'unica cosa che posso dire è:
This is why we can't have nice things.
>
>
>
Vi segnalo questo diario post, che tratta di iD editor:
https://www.openstreetmap.org/user/woodpeck/diary/391175
Ciao Martin
sent from a phone___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it
lic <talk-cz@openstreetmap.org>
> Datum: 27.03.2017 11:55
> Předmět: Re: [Talk-cz] iD editor Strava
>
>Psal jsem na podporu, uvidíme. Třeba rendruji nový dlaždice :)
>
>Dne po 27. 3. 2017 9:54 uživatel Petr Holub <ho...@ics.muni.cz> napsal:
>
>> > Ahoj, všiml
> Ahoj, všiml jsem si že přestal fungovat iD editor s podporou tras Strava
> heat. Nefunguje
> přepínání běh / kolo / oboje, nefunguje zarovnávání podle tras. Zbylo tam jen
> zeleně zobrazené
> vše v jednom, jen do zoomu 15.
> Je to škoda, byl to užitečný nástroj.
> Nepředpokládám, že je chyba
Ahoj, všiml jsem si že přestal fungovat iD editor s podporou tras Strava heat.
Nefunguje přepínání běh / kolo / oboje, nefunguje zarovnávání podle tras. Zbylo
tam jen zeleně zobrazené vše v jednom, jen do zoomu 15.
Je to škoda, byl to užitečný nástroj.
Nepředpokládám, že je chyba jen na mé
I heard a talk from David Bitner on customizing id for adding information
to the Boundary Waters Canoe Area (BWCA.) His github repository with a code
template is https://github.com/missinglinkmaps/custom_id
As I recall, BWCA publishes features for various campsites. Using just a
small subset of
iD is being actively developed and I saw that it's also going modular.
Does anyone have experience using iD editor for custom projects?
Bjenk Ellefsen, PhD
Data Exploration and Integration Lab (DEIL) | Lab d'exploration et
d'intégration de données (LEID)
Center for Special Business Projects
Well, the foundation does exist.
Does this mean everyone creates an account on Bhuvan before starting
to trace in OpenStreetMap? I'm still not clear how this could work.
Might make sense to ask others. Paul, Mikel - do you have thoughts?
Would be good to know what Paul and Mikel think here.
Nice, I finally poked at this. For those on list who don't know tiles
URL syntax, you can drop this URL into ID and it works great!
http://tile1.nrsc.gov.in/tilecache/tilecache.py/1.0.0/bhuvan_imagery2/{zoom}/{x}/{y}.jpg
The subdomain prefix tile1 can be replaced with tile2, 3, 4 (I
guess
Hey Shekhar -
Can we get more clarity on the license before we start using this please?
Again, we need it in writing that this is public domain or usable for
tracing in OpenStreetMap.
We cannot use it otherwise.
On Mon, May 18, 2015 at 2:39 PM, Shekhar Krishnan shek...@topomancy.com wrote:
Has anyone poked around with the tileserver and can report experience so
far? This looks promising.
S.K.
--
Shekhar Krishnan
@bombayologist
http://shekhar.cc
On 18-May-2015 2:04 am, Paul Norman penor...@mac.com wrote:
On 5/16/2015 11:00 PM, Nagarjuna G. wrote:
Do we really need the tiles? If
On Sun, May 17, 2015 at 4:15 AM, Paul Norman penor...@mac.com wrote:
On 5/15/2015 11:39 PM, Devdatta Tengshe wrote:
As far as I know, Bhuvan uses Tilecache.py to serve out Imagery in tiles(
http://tile1.nrsc.gov.in/tilecache/tilecache.py/1.0.0/bhuvan_imagery2/10/719/456.jpg).
The catch is
On 17 May 2015 4:27:46 am IST, Paul Norman penor...@mac.com wrote:
On 5/15/2015 10:33 PM, Sajjad Anwar wrote:
Couple of things to keep in mind here -
1. We'd need open licensing, or it should say that tracing for
OpenStreetMap is permitted.
2. The layers should be in Web Mercator projection.
We should get the raw imagery from them and make it ourselves. ISRO is
under no mandate to provide an API and Bhuvan may just disappear one day.
S.K.
--
Shekhar Krishnan
@bombayologist
http://shekhar.cc
On 17-May-2015 11:39 am, Nagarjuna G. nagar...@gnowledge.org wrote:
On 17 May 2015 4:27:46
This is interesting. I couldn't find though. Can you share a
screenshot? This is particularly interesting for some of us who are
working to make OpenStreetMap software available for outside the
ecosystem.
Just checked, and it certainly is the iD editor:
Ishan can you point us to wms or tiles feeds for Bhuvan? Afaik, they are
not there, but would be hugely useful for all sorts of work.
Sajjad's Nepal precedent is a good one to approach ISRO again for CartoSat
raw data. GN and I want to do this via TIFR, we could also work with Mapbox
India.
I'm
On Sat, May 16, 2015 at 11:54 AM, Shekhar Krishnan
shek...@topomancy.com wrote:
Ishan can you point us to wms or tiles feeds for Bhuvan? Afaik, they are not
there, but would be hugely useful for all sorts of work.
Sajjad's Nepal precedent is a good one to approach ISRO again for CartoSat
raw
Does Bing and OSM have an agreement of this sort? Is it possible to get
a copy or some statements that will help us ask for similar agreement.
Here's the wiki page - http://wiki.openstreetmap.org/wiki/Bing
Here's announcement on Bing blog -
What would be a cool first step is to have a hybrid layer of bhuvan
satellite imagery with osm map overlay. This should be ok with proper
attribution to NRSC/ISRO according to their terms:
http://bhuvan.nrsc.gov.in/bhuvan/bhuvan_terms
Here is the tile request link from the inspector:
On 5/15/2015 10:33 PM, Sajjad Anwar wrote:
Couple of things to keep in mind here -
1. We'd need open licensing, or it should say that tracing for
OpenStreetMap is permitted.
2. The layers should be in Web Mercator projection. There are quite a
few Bhuvan layers that are not.
There's two sides
On 5/15/2015 11:39 PM, Devdatta Tengshe wrote:
As far as I know, Bhuvan uses Tilecache.py to serve out Imagery in
tiles(http://tile1.nrsc.gov.in/tilecache/tilecache.py/1.0.0/bhuvan_imagery2/10/719/456.jpg).
The catch is that this imagery is in Geographic Latlong (i.e.
EPSG:4326) and not in Web
Bhuvan has a TMS/WMS layer, iirc, which can be used with JOSM.
On Fri, May 15, 2015 at 9:35 PM, GN nagar...@gnowledge.org wrote:
We checked Bhuvan today to get some idea. We found that they also use
Id editor for community contributions.
We are trying to get the high resolution satellite
We checked Bhuvan today to get some idea. We found that they also use
Id editor for community contributions.
We are trying to get the high resolution satellite maps from ISRO for
school and college mapping projects that we are currently doing.
If openstreetmap.in would like to get the
Dear GN,
We checked Bhuvan today to get some idea. We found that they also use
Id editor for community contributions.
This is interesting. I couldn't find though. Can you share a
screenshot? This is particularly interesting for some of us who are
working to make OpenStreetMap software
Dobrý den.
S nadšením jsem udělal pár editací OSM (stále se učím jak to dělat
kvalitně a správně). Používám pro editaci webový iD editor, který je
dostupný všude a bez instalace (i když na Atomu je trochu pomalý). Co
mne v tomto editoru chybí je přímá volba lepších leteckých podkladů.
Podklad
Ahoj Marku,
On Mon 13-01-14 15:18:27, Marek Chlup wrote:
Mé dotazy:
Je možné (legální) využívat letecké mapy, které na uvedených službách
ČUZK poskytuje pro editaci OSM map?
Nikoli. Viz
http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Ov.C4.9B.C5.99ovac.C3.AD_zdroje
Děkuji za odpověď.
ČÚZK u ORTOFOTO odkazuje pokud jde o podmínky poskytování (a i užití) na
dokument:
http://geoportal.cuzk.cz/Dokumenty/Podminky_sluzby_CUZK.pdf
ten pak zmiňuje například vyhlášku č. 103/2010 Sb.:
http://inspire.gov.cz/sites/default/files/documents/103_2010.pdf
Chvíli jsem si to
Ahoj, myslím, že nejlíp přes databázi podkladů, které iD používá:
https://github.com/osmlab/editor-imagery-index
Honza Vršovský
-- Původní zpráva --
Od: Marek Chlup m...@chlup.net
Datum: 13. 1. 2014
Předmět: Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
Děkuji za
/editor-imagery-index
Honza Vršovský
-- Původní zpráva --
Od: Marek Chlup m...@chlup.net
Datum: 13. 1. 2014
Předmět: Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
Děkuji za odpověď.
ČÚZK u ORTOFOTO odkazuje pokud jde o podmínky poskytování (a i užití) na
...@chlup.net
Datum: 13. 1. 2014
Předmět: Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
Hmm. Tady:
https://github.com/osmlab/editor-imagery-index/blob/gh-pages/sources/europe/
CzechCUZKKM.json
je dokonce definice pro KM.
Marek
On Mon, Jan 13, 2014 at 08:13:05PM +0100, Jan Vršovský wrote
...@chlup.net
Datum: 13. 1. 2014
Předmět: Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
Hmm. Tady:
https://github.com/osmlab/editor-imagery-index/blob/gh-pages/sources/europe/
CzechCUZKKM.json
je dokonce definice pro KM.
Marek
On Mon, Jan 13, 2014 at 08:13:05PM +0100, Jan Vršovský
J'ai eu un cas similaire vers chez moi avec un multipolygone
landuse=residential passé en amenity=kindergarten.
Ca ressemble fort à un bug d'iD car je ne vois pas comment un multipolygone
se retrouve ainsi modifié vu l'interface limitée d'iD vis à vis des
relations...
Le 10 septembre 2013
Idem (voir la querelle sur le découpage des landuses)
Une macro relation meadow était devenu un hameau !
--
View this message in context:
http://gis.19327.n5.nabble.com/id-editor-tp5776994p5777092.html
Sent from the France mailing list archive at Nabble.com.
Le mercredi 11 septembre 2013 à 09:25 +0200, Christian Quest a écrit :
J'ai eu un cas similaire vers chez moi avec un multipolygone
landuse=residential passé en amenity=kindergarten.
Ca ressemble fort à un bug d'iD
c'est confirmé :
https://github.com/systemed/iD/issues/542
car je ne vois
bonjour,
j'ai remarqué depuis peut de temps qu'avec l'éditeur id, des landuses
sont modifiés en pub, building, etc
comme ici
http://www.openstreetmap.org/browse/way/37855829
c'est plus un hasard ou vous l'avez aussi remarqué ?
didier
___
Talk-fr
Idem.
http://www.openstreetmap.org/browse/way/41691713
Ce polygone est une zone résidentielle. La semaine dernière, c'est
devenu un bâtiment, puis un landuse, puis un bar et de nouveau une
zone résidentielle.
Le 10 septembre 2013 17:46, didier2020 didier2...@free.fr a écrit :
bonjour,
j'ai
我在那上面看到兩位幫忙翻譯的朋友，分別是 hlaw 、 xavier114fch。
有寫信跟兩位聯繫，其中來自香港的 hlaw 有回應 (上個月了, sorry)，他的意思是：main
branch的譯文，應純為翻譯，因此在翻譯時維持了通用性，即使是台灣用戶，也可編輯其他地方的道路。因此套用地區性的 tagging
標準於編輯器中也許未必合適。
李昕迪 Lee, Sin-di mcd...@gmail.com 於 2013年5月11日下午9:47 寫道：
我的想法是 iD 如果設定是門檻比較低的編輯器，是不是給新手的障礙可以降低到不必一定要去看 Taiwan tagging
Am 15.05.2013 16:53, schrieb fly:
Und ich würde gerne Deine Alternativen wissen bevor Du sie als
deprecated markieren willst.
Wurde schon vorgeschlagen, aber halt nochmals: man könnte die (jetzt
ohne waterway) 7 Tags mit :right und/oder :left Tags ergänzen. Wenn ich
richtig gesehen habe wäre
Hi,
Am Thu, 16 May 2013 09:56:57 +0200
schrieb Simon Poole si...@poole.ch:
cliff:left=up
Sollte das nicht besser high/low sein?
Mapper A: Von links gesehen ist es eine Aufwärtskante.
Mapper B: Nach links geht es aufwärts.
Wilhelm
___
Talk-de
Hi.
Für eine generalisiertere Regel ist das trotzdem schwierig:
Dein Beispiel:
cliff:left=up
wird beim Umdrehen des Weges ohne semantische Änderung zu
cliff:right=up
Beispiel von mir:
highway=steps
direction=up
wird beim Umdrehen des Weges ohne semantische Änderung aber zu
direction=down
Wo
Am 16.05.2013 10:19, schrieb Peter Wendorff:
Oder sehe ich hier die Tags nicht, die dir abei vorschweben?
barrier=city_wall
http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dcity_wall
Aber vielleicht versteh ich da die Semantik nicht richtig.
Simon
Woher dichtest du dir da das inside/outside?
Auf der von dir verlinkten englischsprachigen Seite jedenfalls steht
davon nichts, da steht nur two_sided=yes.
Und da dazu sonst nichts dokumentiert ist, sehe ich keinen Grund, warum
nicht auch hier left/right genutzt werden sollte; zumal die wenigsten
Es gibt um den Tagwert, nicht ob links oder rechts im Tagnamen gebraucht
wird (also barrier=city_wall, city_wall:left=inside). Die
unterschiedliche Höhe im inneren vs ausserhalb der Mauer, scheint mir
nur etwas schwierig zum bestimmen und im allgemeinen gibt es aber bei
einer Stadtmauer ein
Hi,
Am Thu, 16 May 2013 09:56:57 +0200
schrieb Simon Poole si...@poole.ch:
Wurde schon vorgeschlagen, aber halt nochmals: man könnte die (jetzt
ohne waterway) 7 Tags mit :right und/oder :left Tags ergänzen. Wenn
ich richtig gesehen habe wäre es sinnvoll: jeweils up, down,
high,low oder
Einverstanden, aber das inside/outside müsste ja in diesem Fall nicht
angepasst werden:
city_wall:left=inside wird beim umdrehen zu city_wall:right=inside und
alles bleibt korrekt.
Gruß
Peter
Am 16.05.2013 11:07, schrieb Simon Poole:
Es gibt um den Tagwert, nicht ob links oder rechts im
Am 16.05.2013 09:56, schrieb Simon Poole:
Beispiel Tagging:
natural=cliff
cliff:left=up
(cliff:right=down)
Meiner Meinung nach sollte bei so etwas left/right in den Wert. Also
cliff:lower_side = left/right
city_wall:inside = left/right
oder auch
flow = forward/backward/(alternating)
Die
Am 16. Mai 2013 10:36 schrieb Simon Poole si...@poole.ch:
Am 16.05.2013 10:19, schrieb Peter Wendorff:
Oder sehe ich hier die Tags nicht, die dir abei vorschweben?
barrier=city_wall
http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dcity_wall
Aber vielleicht versteh ich da die Semantik
Am 16.05.2013 11:37, schrieb Tobias Knerr:
Am 16.05.2013 09:56, schrieb Simon Poole:
Beispiel Tagging:
natural=cliff
cliff:left=up
(cliff:right=down)
Meiner Meinung nach sollte bei so etwas left/right in den Wert. Also
cliff:lower_side = left/right
city_wall:inside = left/right
oder
Am 16. Mai 2013 10:53 schrieb Peter Wendorff wendo...@uni-paderborn.de:
Woher dichtest du dir da das inside/outside?
Auf der von dir verlinkten englischsprachigen Seite jedenfalls steht
davon nichts, da steht nur two_sided=yes.
Und da dazu sonst nichts dokumentiert ist, sehe ich keinen
Hallo,
für Objekte ohne Zusatztag werden die Auswerter und Editoren sich schon
an dem bisherigen Default orientieren. Wenn dann in Zukunft ein solcher
Weg ungedreht wird, wird der Editor also bspw. dann das entsprechende
Zusatztag setzen.
Henning
Am 16.05.2013 11:09, schrieb Wilhelm
Am 16.05.2013 12:01, schrieb Simon Poole:
Der Vorteil von *:left und *:right im Tagnamen ist, dass es von den
jetzigen Editoren schon unterstützt würde (Renderer müssten natürlich
nachziehen). Jeder Tag mit solcher Semantik im Tagwert braucht einfach
wieder ein Sonderbehandlung.
Also
Hi,
Am Thu, 16 May 2013 12:43:30 +0200
schrieb Henning Scholland o...@aighes.de:
für Objekte ohne Zusatztag werden die Auswerter und Editoren sich
schon an dem bisherigen Default orientieren. Wenn dann in Zukunft ein
solcher Weg ungedreht wird, wird der Editor also bspw. dann das
Am 16. Mai 2013 13:26 schrieb Wilhelm Spickermann o...@spickermann-d.de:
Ein noch nicht
umgestellter OSMI würde falsche Fehlermeldungen erzeugen. Noch
nicht umgestellte Renderer würden Mapper zu unsinnigen Änderungen
anregen.
Das ist der Preis der Flexibilität, wir könnten ja nichts mehr
Hallo,
so sehe ich das auch. Ich denke auch, dass die großen bekannten Tools da
recht schnell drauf reagieren würden. Ich denke, dass alleine der
Vorteil, dass vielen Mappern die Arbeit mit den Daten erleichtert den
Nachteil relativiert. Erleichtert meint, dass man sich nicht mehr
gedanken
Hi,
Am Thu, 16 May 2013 13:37:12 +0200
schrieb Martin Koppenhoefer dieterdre...@gmail.com:
Das ist der Preis der Flexibilität, wir könnten ja nichts mehr
hinzufügen oder anpassen, wenn wir diesem Argument folgen würden. Ich
sage nicht, dass das völlig von der Hand zu weisen ist, aber es ist
Zitat Wilhelm Spickermann:
Am Thu, 16 May 2013 13:37:12 +0200
schrieb Martin Koppenhoefer dieterdre...@gmail.com:
Das ist der Preis der Flexibilität, wir könnten ja nichts mehr
hinzufügen oder anpassen, wenn wir diesem Argument folgen würden. Ich
sage nicht, dass das völlig von der Hand zu
Am Thu, 16 May 2013 14:53:16 +0200
schrieb Michael Buege mich...@buegehome.de:
Etwa so: Nach Abstimmung eines Proposals wird dieses eingefroren
(unveränderlich gemacht) und ihm wird zentral eine Nummer gegeben.
[...]
Abstimmungen über Proposals haben keine bindende Wirkung und werden
Bei anderen Programmen habe ich eine gute Lösungsmöglichkeit gesehen:
Da wird die Warnung zunächst jedesmal gezeigt, bis man sie abwählt.
Dennoch erscheint die Meldung noch dreimal in größer werdenden
Abständen, wobei man sie wieder aktivieren kann.
malenki o...@malenki.ch wrote:
Es wird
On 13.05.2013 16:10, Simon Poole wrote:
Am 13.05.2013 14:43, schrieb Ronnie Soak:
oneway gehört nicht zu den genannten (4 nach meine Zählung) Tags da sich
mit oneway=-1 die Richtung umkehren lässt, was die meisten Editoren und
Anwendungen auch unterstützen.
Die 4 Tags sind übrigens (kann
Danke für input an alle. @jfirebaugh, mein Kollege und iD Programmierer hat
soeben eine neue iD Roadmap für 1.1 gepostet [1]. Sie beinhaltet auch
umfangreicheren relations support. Viele der Bedenken die hier aufkamen
sollten also mit 1.1 befriedigt sein. Genaue release Daten werden sich in
den
Wie soeben auch auf [talk] gepostet:
Ich bitte alle, die auf konkrete Bugs in iD stossen, diese auf der issue
queue [1] mit einem neuen issue zu beschreiben. Das hilft den iD
Programmierern den editor besser und robuster zu machen.
Danke für die Mithilfe und alles Beste -
Alex
Hallo
Das würde ich nicht unbedingt sagen. Bspw. wenn ich einen Teil des
Umrisses eines Waldes parallel verschieben möchte, um es als Fluss etc.
zu nutzen. Dann trenne ich den Wald auf, mache die Operationen und dann
schließe ich den Wald wieder. Da ist das Erzeugen des MP überflüssig.
Übersetzung:
Wir haben nicht vor, Warnungen für das Umkehren von Wegrichtungen
anzeigen zu lassen. Warnungen mögen gut gemeint sein, laufen aber dem
Ziel von iD zuwider, neue Nutzer zu Kartenbeiträgen zu ermutigen, weil
sie [die Warnungen] die Nutzer verunsichern, auch wenn die
Bearbeitungen
Hi,
Am Tue, 14 May 2013 08:42:42 +0200
schrieb Henning Scholland o...@aighes.de:
Bspw. wenn ich einen Teil des
Umrisses eines Waldes parallel verschieben möchte, um es als Fluss
etc. zu nutzen. Dann trenne ich den Wald auf, mache die Operationen
und dann schließe ich den Wald wieder. Da ist
Hallo,
das hört sich sinnvoll an. Hast du das den josm-devvs schon vorgeschlagen?
Henning
Am 14.05.2013 09:27, schrieb Wilhelm Spickermann:
Hi,
Am Tue, 14 May 2013 08:42:42 +0200
schrieb Henning Scholland o...@aighes.de:
Bspw. wenn ich einen Teil des
Umrisses eines Waldes parallel
Hi,
Am Tue, 14 May 2013 10:22:59 +0200
schrieb Henning Scholland o...@aighes.de:
Hallo,
das hört sich sinnvoll an. Hast du das den josm-devvs schon
vorgeschlagen?
Henning
Nein. Ein Vollautomatik würde vielleicht auch nicht zum JOSM passen.
Ich bin da unsicher.
Vielleicht eher in Form von
Hi,
On Tue, May 14, 2013 at 01:18:10AM +0200, Henning Scholland wrote:
Ob die Nutzer nun von Programmmeldungen verunsichert werden, oder
von den empörten Mitmappern, die sich über die ganzen Zerstörungen
aufregen läuft dann aber letztlich aufs gleiche hinaus. Dann aber
lieber mit
Am 14. Mai 2013 12:03 schrieb Florian Lohoff f...@zz.de:
Andere dinge lassen sich auch leicht fixen denke ich man muss sie
nur mal versuchen exakt zu beschreiben und ein ticket dafuer aufmachen
dann kann man ja code einbauen der das verhindert.
Sehe ich auch so, die Programmierer haben
Hallo,
Am Dienstag, den 14.05.2013, 12:08 +0200 schrieb Martin Koppenhoefer:
Am 14. Mai 2013 12:03 schrieb Florian Lohoff f...@zz.de:
Andere dinge lassen sich auch leicht fixen denke ich man muss sie
nur mal versuchen exakt zu beschreiben und ein ticket dafuer aufmachen
dann kann man ja
Hallo Wolfgang,
das klingt erstmal nach einer recht guten Idee. Vor allem auch, weil es
dadurch für den Mapper einfacher zu verstehen wird welche Tags
richtungsabhängig sind. Bei einer Klippe oder einer Küstenlinien ist
sowas nicht gerade selbsterklärend. Einen weiteren Vorteil sehe ich
Am 14. Mai 2013 13:21 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:
Dann wird einmal
definiert, nach welcher Regel (Muster) die Begriffe umzustellen sind
beim Umdrehen und gut ist.
oneway=forward/backward
coastline=yes
sea=right/left
Bestehende Software kann sehr leicht das neue
Am 14.05.2013 13:22 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:
Es stellt sich die Frage, ob richtungsgebundene tags überhaupt
erforderlich (und sinnvoll) sind.
Die Geschichte mit dem oneway ist historisch gewachsen, als es noch kaum
Probleme gab. Dann/davor kamm die Coastline. Das
On Tue, May 14, 2013 at 01:21:23PM +0200, Wolfgang Hinsch wrote:
wäre es denn, damit grundsätzlich aufzuräumen und alles auf die
forward/backward oder left/right-Tags umzustellen. Dann wird einmal
definiert, nach welcher Regel (Muster) die Begriffe umzustellen sind
beim Umdrehen und gut ist.
Ich finde auch, dass unnötige Warnungen für Anfänger eher abschreckend
sind, aber beim Löschen von Elementen, die Teil einer Relation sind, MUSS
es meiner Meinung nach eine Warnmeldung geben. Gerade weil Anfänger (öfters
als erfahrene Mapper) etwas löschen und dann neuzeichnen anstatt es nur zu
On 11.05.2013 07:02, Jo wrote:
2013/5/11 malenki o...@malenki.ch
Tirkon schrieb:
[keine Warnung beim Umkehren von Wegen, keine Warnung beim Löschen von
Relationsmitgliedern...]
Nach dem Lesen dieses Threads schrieb ich im IRC versehentlich in #osm
statt in #osm-de, wodurch eine
Am 13.05.2013 14:09, schrieb fly:
JOSM kann es und für Potlatsch gibt es einen Bug Report, aber warum
halten die Entwickler von iD tags wie cliff oder retaining_wall für
unwichtig und erlauben weiterhin das Umdrehen.
Ich zitiere aus einem bisschen JavaDoc das ich gerade geschrieben habe:
Ich zitiere aus einem bisschen JavaDoc das ich gerade geschrieben habe:
/**
* There is a set of tags which lead to a way not being reversable,
this is EXTREMLY stupid and should be depreciated immediately.
* @return true if somebody added the brain dead tags
*/
Deine
2013/5/13 Ronnie Soak chaoschaos0...@googlemail.com
Ich zitiere aus einem bisschen JavaDoc das ich gerade geschrieben habe:
/**
* There is a set of tags which lead to a way not being reversable,
this is EXTREMLY stupid and should be depreciated immediately.
* @return
oneway gehört nicht zu den genannten (4 nach meine Zählung) Tags da sich
mit oneway=-1 die Richtung umkehren lässt, was die meisten Editoren und
Anwendungen auch unterstützen.
Die 4 Tags sind übrigens (kann natürlich noch mehr geben)
natural=cliff
natural=coastline
barrier=retaining_wall
On 13/mag/2013, at 16:10, Simon Poole si...@poole.ch wrote:
Die 4 Tags sind übrigens (kann natürlich noch mehr geben)
natural=cliff
natural=coastline
barrier=retaining_wall
man_made=embankment
+1
barrier=city_wall gehört z.B. auch dazu.
Gruß Martin
Am 13.05.2013 15:45, schrieb Martin Koppenhoefer:
ich finde auch, mit einem abwertenden Kommentar in irgendeiner Software ist
da nichts gewonnen. Es gibt nunmal einige tags, die richtungsabhängig sind,
gerade weil in den letzten 10 Jahren noch niemand einen Alternativvorschlag
bringen
Am 13.05.2013, 16:10 Uhr, schrieb Simon Poole si...@poole.ch:
natural=cliff
natural=coastline
barrier=retaining_wall
man_made=embankment
Am 13.05.2013, 16:18 Uhr, schrieb Martin Koppenhoefer
dieterdre...@gmail.com:
barrier=city_wall gehört z.B. auch dazu.
...aber nur wenn two_sided=yes
Am 13.05.2013 14:10 schrieb fly lowfligh...@googlemail.com:
Ich werde also in Zukunft die Entwickler anschreiben und sie bitten die
Fehler in der Datenbank zu korrigieren und in Kontakt mit den Nutzern
ihrer Software zu treten. Ich habe nämlich keine Lust mehr mich wie mit
Fußengetreten zu
Am 13. Mai 2013 16:29 schrieb Martin Raifer tyr@gmail.com:
Außerdem verstehe ich nicht, wieso man_made=embankment in dieser Liste
auftaucht.
weil Dämme auch oft 2 unterschiedliche Seiten (innen und aussen) haben.
Gruß Martin
___
Talk-de
Achos, es geht also nicht um wege, die sich nicht umdrehen lassen, sondern
um tags, die sich nicht umdrehen lassen.
Ok. Das kam bei mir bisher nicht so an.
oneway=-1 war mir bis dato zudem unbekannt. Ist aber tatsaechlich im Wiki
dokumentiert.
(Wenn auch als deprecated mit dem dem Hinweis auf
Am 13.05.2013 16:29, schrieb Martin Raifer:
.
...aber nur wenn two_sided=yes nicht gesetzt ist. Außerdem können
barrier=city_wall und natural=cliff auch auf Flächen benutzt werden,
dann ist eine Richtungsumkehrung wieder uneingeschränkt erlaubt.
Außerdem verstehe ich nicht, wieso
Die (mittlerweilen) 5
Ausnahmen, lassen als Lösung nur zu dem Benutzer mitzuteilen: Kannst du
nicht machen oder Wenn du das machst, machst du was kaputt, die Wege
sind wirklich nicht umkehrbar.
Was spricht gegen diese Loesung?
Gruss,
Chaos
___
Ich seh immernoch den tieferen Sinn nicht überhaupt ein umdrehen von Wegen
anzubieten.
Kann mir jemand mal den Vorteil vom umdrehen erklären?
Ich mach das immer nur VOR dem eintragen von Lanes-Tags, damit alle Wege
zu der Kreuzung hin führen.
Ich geh davon aus das kein Anfänger was an
Am 13.05.2013 16:45, schrieb Ruben Kelevra:
Ich seh immernoch den tieferen Sinn nicht überhaupt ein umdrehen von Wegen
anzubieten.
Die üblichen expliziten Fälle sind Kreisverkehre und Einbahnstrassen.
Implizit beim Verbinden von Wegen.
Simon
___
Am 13.05.2013, 16:28 Uhr, schrieb Simon Poole si...@poole.ch:
[...] lassen als Lösung nur zu dem Benutzer mitzuteilen: Kannst du
nicht machen oder Wenn du das machst, machst du was kaputt, die Wege
sind wirklich nicht umkehrbar.
1 - 100 di 150 matches
Mail list logo
