Re: [Talk-it] iD editor
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 mi sembra troppo, proporrei 6 mesi, considerati gli errori indotti dalla taggatura ID in alcuni contesti resa coatta da questi membri sviluppatori di ID, errori che in 6 mesi se ne fanno a bizzeffe considerando l'uso massivo di questo editor, errori che poi bisognerà correggere. -- _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| Simone Girardelli ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] iD editor
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 discussione in talk-de e > forum. > > Ciao > Martin > > > ___ Iniziativa giusta e che aspettavo da un pezzo. Voterò a favore. Grazie Lorenzo ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] iD editor
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 < dieterdre...@gmail.com> ha scritto: > 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 le persone che ti pagano. >> >>> >>> >> Perché prima andava bene la do-ocracy mentre adesso si chiede la >> dem-ocracy? >> > > > no, c'é una differenza tra do-ocracy e autocracy / oligarchia. Non puoi > ignorare tutti gli altri, sopratutto se sei responsabile e al potere > dell'unico editore sulla pagina principale. Non puoi chiudere ogni > discussione (sulla cosa, portata avanti in modo civile) che non ti piaccia > sui ticket di Github, o meglio, lo puoi fare ma vuol dire che ti sposti > fuori da solo. > > Un esempio tra tanti è questo post di Bryan, dove spiega cosa non ha > alcuna influenza sulle decisioni che fanno al riguardo del tagging: > > Some things that don't really factor at all into our decision: >> >>- how long a tag with implicit semantics has been in use >>- how many softwares (renderers / routers or whatever) already >>support the implicit rule >>- how frequently the tag is used >>- what a handful of people on a mostly dormant mailing list think >>- what one person has written on the osm wiki >>- how many downvotes you encourage people to put on our issue list >>- what they are saying about us in the weekly osm tabloid >> >> https://github.com/openstreetmap/iD/issues/6409 > > > E' contro lo spirito e le regole del progetto se il numero di utilizzi di > un tag non ha importanza. E guarda un po', basta metterlo in un preset di > iD e dopo poco sarà utilizzato numerosamente, anche se un altro tag già > c'era. > > Vi segnalo inoltre che "la communità tedesca" sta preparando un documento > programmatico per presentare una posizione coordinata e concordata. Una > prima bozza si trova qui: > >> >> https://wiki.openstreetmap.org/wiki/User:Nakaner/Forderungen_zur_Zukunft_von_iD >> >> traduzione automatica: >> Utente:Nakaner/Richieste sul futuro di iD >> Questa è una bozza. Le modifiche sono benvenute. Per l'accordo nel forum >> tedesco o su Talk-de è richiesto. --22:21, 12 novembre 2019 (UTC) >> >> Si tratta di un progetto di posizione comune della comunità tedesca >> dell'OSM su cui votare dopo averne discusso la versione provvisoria. La >> discussione si svolgerà nei seguenti luoghi: >> >> Il forum >> Mailing list Talk-en >> >> Progetto: Requisiti per il futuro di iD-Editor >> >> L'iD-Editor è indispensabile per facilitare i principianti ad iniziare a >> lavorare con OpenStreetMap. Gli eventi del progetto iD su GitHub e il >> comportamento dei suoi due principali sviluppatori ci riempiono di grande >> insoddisfazione e preoccupazione. >> >> I redattori online erano e sono un fastidio per molti mappatori esperti, >> perché sono preferiti da mappatori inesperti e nuovi, che ovviamente >> commettono errori. Tuttavia, a causa dell'inesperienza dei loro utenti e >> del loro posizionamento come editor standard su www.openstreetmap.org, i >> principali sviluppatori hanno una responsabilità particolare. L'editor che >> vi viene offerto è utilizzato principalmente da mappatori nuovi e >> inesperti. Gli errori nell'editor possono essere notati in seguito, perché >> i mappatori più esperti usano principalmente JOSM. Come per tutti i >> redattori popolari, le decisioni mirate a favore o contro un tag hanno una >> grande influenza sui dati - e questo in un progetto in cui i tag prevalgono >> regolarmente sugli altri perché sono votati con i piedi (cioè l'uso dei >> tag). >> >> Infatti, le richieste di mappatori esperti sugli editor online sono >> elevate - troppo elevate a seconda del proprio punto di vista - e gli >> errori dei nuovi arrivati sono spesso attribuiti anche agli sviluppatori. I >> mappatori più anziani ricordano nei forum e sulle mailing list discussioni >> senza fine sulle carenze dell'editor iD nel trattare le relazioni. Da >> questo punto di vista l'editore non è in alcun modo inferiore al suo >> predecessore Potlatch ed ha difficoltà ad essere apprezzato da mappatori >> esperti. >> >> L'annuncio di qualche mese fa che iD dovrebbe ottenere un validatore ha >> suscitato la speranza che l'editore farà più giustizia al suo compito. >> Tuttavia, queste speranze non sono state soddisfatte. Al contrario, invece >> di riconoscere ed evitare gli errori tipici degli utenti in modo >> responsabile, cauto e prudente, i principali sviluppatori stanno >> spudoratamente sfruttando la loro posizione di potere per la propria agenda. >> >> Anche
Re: [Talk-it] iD editor
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 segnalazione. Concordo pienamente col documento da te condiviso, quindi sarei molto favorevole alla sottoscrizione come comunità italiana. Ciao, Federico ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] iD editor
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 qualcosa e usare come "cavallo di troia" l'editor principale usato dai newbies è ancora più urtante. Concordo appieno nell'appoggiare la proposta della comunità tedesca. Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] iD editor
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 forum. > si, a parere mio dovremmo firmarla anche noi come comunità italiana. mi sembra molto ben fatta e le richieste sono del tutto accettabili > Ciao > Martin > -- ciao Luca www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] iD editor
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 le persone che ti pagano. > >> >> > Perché prima andava bene la do-ocracy mentre adesso si chiede la > dem-ocracy? > no, c'é una differenza tra do-ocracy e autocracy / oligarchia. Non puoi ignorare tutti gli altri, sopratutto se sei responsabile e al potere dell'unico editore sulla pagina principale. Non puoi chiudere ogni discussione (sulla cosa, portata avanti in modo civile) che non ti piaccia sui ticket di Github, o meglio, lo puoi fare ma vuol dire che ti sposti fuori da solo. Un esempio tra tanti è questo post di Bryan, dove spiega cosa non ha alcuna influenza sulle decisioni che fanno al riguardo del tagging: Some things that don't really factor at all into our decision: > >- how long a tag with implicit semantics has been in use >- how many softwares (renderers / routers or whatever) already support >the implicit rule >- how frequently the tag is used >- what a handful of people on a mostly dormant mailing list think >- what one person has written on the osm wiki >- how many downvotes you encourage people to put on our issue list >- what they are saying about us in the weekly osm tabloid > > https://github.com/openstreetmap/iD/issues/6409 E' contro lo spirito e le regole del progetto se il numero di utilizzi di un tag non ha importanza. E guarda un po', basta metterlo in un preset di iD e dopo poco sarà utilizzato numerosamente, anche se un altro tag già c'era. Vi segnalo inoltre che "la communità tedesca" sta preparando un documento programmatico per presentare una posizione coordinata e concordata. Una prima bozza si trova qui: > > https://wiki.openstreetmap.org/wiki/User:Nakaner/Forderungen_zur_Zukunft_von_iD > > traduzione automatica: > Utente:Nakaner/Richieste sul futuro di iD > Questa è una bozza. Le modifiche sono benvenute. Per l'accordo nel forum > tedesco o su Talk-de è richiesto. --22:21, 12 novembre 2019 (UTC) > > Si tratta di un progetto di posizione comune della comunità tedesca > dell'OSM su cui votare dopo averne discusso la versione provvisoria. La > discussione si svolgerà nei seguenti luoghi: > > Il forum > Mailing list Talk-en > > Progetto: Requisiti per il futuro di iD-Editor > > L'iD-Editor è indispensabile per facilitare i principianti ad iniziare a > lavorare con OpenStreetMap. Gli eventi del progetto iD su GitHub e il > comportamento dei suoi due principali sviluppatori ci riempiono di grande > insoddisfazione e preoccupazione. > > I redattori online erano e sono un fastidio per molti mappatori esperti, > perché sono preferiti da mappatori inesperti e nuovi, che ovviamente > commettono errori. Tuttavia, a causa dell'inesperienza dei loro utenti e > del loro posizionamento come editor standard su www.openstreetmap.org, i > principali sviluppatori hanno una responsabilità particolare. L'editor che > vi viene offerto è utilizzato principalmente da mappatori nuovi e > inesperti. Gli errori nell'editor possono essere notati in seguito, perché > i mappatori più esperti usano principalmente JOSM. Come per tutti i > redattori popolari, le decisioni mirate a favore o contro un tag hanno una > grande influenza sui dati - e questo in un progetto in cui i tag prevalgono > regolarmente sugli altri perché sono votati con i piedi (cioè l'uso dei > tag). > > Infatti, le richieste di mappatori esperti sugli editor online sono > elevate - troppo elevate a seconda del proprio punto di vista - e gli > errori dei nuovi arrivati sono spesso attribuiti anche agli sviluppatori. I > mappatori più anziani ricordano nei forum e sulle mailing list discussioni > senza fine sulle carenze dell'editor iD nel trattare le relazioni. Da > questo punto di vista l'editore non è in alcun modo inferiore al suo > predecessore Potlatch ed ha difficoltà ad essere apprezzato da mappatori > esperti. > > L'annuncio di qualche mese fa che iD dovrebbe ottenere un validatore ha > suscitato la speranza che l'editore farà più giustizia al suo compito. > Tuttavia, queste speranze non sono state soddisfatte. Al contrario, invece > di riconoscere ed evitare gli errori tipici degli utenti in modo > responsabile, cauto e prudente, i principali sviluppatori stanno > spudoratamente sfruttando la loro posizione di potere per la propria agenda. > > Anche con i modelli di tagging, gli sviluppatori principali sono troppo > sfacciato. Che si tratti di ignorare il consenso dei canali di > comunicazione stabiliti a tal fine, o che semplicemente cancellano tutte le > argomentazioni avanzate, anche se le cose vengono mappate in modo diverso > al di fuori degli Stati Uniti. L'enumerazione dei casi andrebbe oltre lo > scopo di questo testo, quindi ci riferiamo a ID/Controversial_Decisions. > >
Re: [Talk-it] iD editor
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 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 > ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] iD editor
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'è bisogno che > constringiamo tutti a portarsi il cavallo di troia in casa, so perché Josm > è troppo complicato o richiede java. La domanda è si "opt-in" o "opt-out". > > Va anche benissimo che un utente si scelga un "benevolente (?) dittatore" > che fa le decisioni per lui/lei, ma deve essere una scelta. Attualmente gli > utenti di iD, al meno la maggiorparte, non sono coscienti che le > "correzioni automatiche" che iD li propone, oppure certi tags, che iD ha > introdotti (introdotti, non scelti da quelli diffusi), sono quelli della > minoranza, quelli che la communità non ha ne discussi, ne approvati. > > 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 le persone che ti pagano. > > Perché prima andava bene la do-ocracy mentre adesso si chiede la dem-ocracy? > Ciao > Martin > ___ > Talk-it mailing list > Talk-it@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-it > ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] iD editor
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 richiede java. La domanda è si "opt-in" o "opt-out". Va anche benissimo che un utente si scelga un "benevolente (?) dittatore" che fa le decisioni per lui/lei, ma deve essere una scelta. Attualmente gli utenti di iD, al meno la maggiorparte, non sono coscienti che le "correzioni automatiche" che iD li propone, oppure certi tags, che iD ha introdotti (introdotti, non scelti da quelli diffusi), sono quelli della minoranza, quelli che la communità non ha ne discussi, ne approvati. 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 le persone che ti pagano. Ciao Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] iD editor
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. > > > Ciao Martin > > sent from a phone > ___ > Talk-it mailing list > Talk-it@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-it > ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] iD editor
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
Re: [Talk-cz] iD editor Strava
iD editor Strava už funguje tak jako dříve. Nové dlaždice bohužel nejsou, taky jsem tajně doufal. Stávající 2015 stačí. Díky za pomoc. Milan __ > Od: Petr Schönmann <pschonm...@gmail.com> > Komu: OpenStreetMap Czech Republic <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 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é straně, ale pro jistotu to prosím >> zkuste někdo ověřit. >> >> Mne jede - jen nejde zapnout ta vrstva Strava Cycling Heatmap, ale to >> se zda spis jako problem nekde na strane TMS Stravy, protoze to ted >> nefunguje ani v JOSM a dava to 400 ERROR. >> >> Petr >> >> >> ___ >> Talk-cz mailing list >> Talk-cz@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-cz >> >-- >S pozdravem >Petr Schönmann >https://www.facebook.com/klikklakcz > > >-- > >___ >Talk-cz mailing list >Talk-cz@openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk-cz > > ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] iD editor Strava
> 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é straně, ale pro jistotu to prosím > zkuste někdo ověřit. Mne jede - jen nejde zapnout ta vrstva Strava Cycling Heatmap, ale to se zda spis jako problem nekde na strane TMS Stravy, protoze to ted nefunguje ani v JOSM a dava to 400 ERROR. Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] iD editor Strava
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é straně, ale pro jistotu to prosím zkuste někdo ověřit. Díky. http://strava.github.io/iD Milan ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-ca] iD editor
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 tags, his modified version allows for quick adding of features. in the US, the National Park Service has a modified version of iD that updates OSM and sends a copy of the changes to NPS for review for NPS maps. I don't believe it's been rolled out to the public yet. Let me know if you need more information. I can put you in touch with either David or NPS. Clifford On Wed, Jun 15, 2016 at 6:37 AM, Ellefsen, Bjenk (STATCAN) < bjenk.ellef...@canada.ca> wrote: > > 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 | Centre des Projets Spéciaux sur les > entreprises > Statistics Canada | Statistiques Canada > (343) 998-3004 > > > > > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ca > > -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] iD editor
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 | Centre des Projets Spéciaux sur les entreprises Statistics Canada | Statistiques Canada (343) 998-3004 ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-in] Id editor on Bhuvan
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. It seems a question of what is public domain, not just according to OSM but also per Indian law. Apart from the discussions on Bing and the License Working Group, this is the only statement I find on the OSM wiki: https://wiki.openstreetmap.org/wiki/Legal_FAQ#2._Contributing Hmm, 20 tiles a day is not going to work. This is going to be high traffic. And it does require reliable infrastructure. Worthwhile to consider how we can support Bhuvan on this. Also, few imagery are not in web mercator, those will have to be reprojected. Yes, agreed, the 20 per day limit I see is not just for GeoTIFF downloads but also for the tile service. There could perhaps then be a role for HBCSE-TIFR here as a educational institution, and government client able to redistribute and serve high-availability imagery for scientific and developmental purposes to the OSM community. The fact that Bhuvan is already using ID, tilecache, etc. is the opening I believe Nagarjuna was looking for when he initiated this thread. We are ready to approach NSRC and ISRO via TIFR to support using Bhuvan for OSM mapping, if folks here can advise on what we should ask for. We're also approaching them for raw data which we're using for image processing and analysis at HBCSE. S.K. -- Shekhar Krishnan @bombayologist http://shekhar.cc ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Id editor on Bhuvan
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 these are backup servers?)
S.K.
On Sunday 17 May 2015 03:36 PM, Arun Ganesh wrote:
On Sun, May 17, 2015 at 4:15 AM, Paul Norman penor...@mac.com
mailto: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 that this imagery is in Geographic Latlong (i.e.
EPSG:4326) and not in Web mercator
Those are standard map tiles, in Web Mercator.
You can compare http://tile.openstreetmap.org/10/719/456.png and
http://tile1.nrsc.gov.in/tilecache/tilecache.py/1.0.0/bhuvan_imagery2/10/719/456.jpg
to see that they are the same area.
Thanks Paul, after poking around stumbled on their full list of tile layers:
http://tile1.nrsc.gov.in/tilecache/tilecache.py/1.0.0/layers
bhuvan_imagery is in WGS84
bhuvan_imagery2 is in web mercator
The tms url for bhuvan_imagery2:
tms:http://tile{switch:1,2,3,4}.nrsc.gov.in/tilecache/tilecache.py/1.0.0/bhuvan_imagery2/{zoom}/{x}/{y}.jpg
http://nrsc.gov.in/tilecache/tilecache.py/1.0.0/bhuvan_imagery2/%7Bzoom%7D/%7Bx%7D/%7By%7D.jpg
--
Arun Ganesh
(planemad) http://en.wikipedia.org/wiki/User:Planemad
http://j.mp/ArunGanesh
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in
--
Shekhar Krishnan
@bombayologist
http://shekhar.cc
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Id editor on Bhuvan
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:
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
these are backup servers?)
S.K.
On Sunday 17 May 2015 03:36 PM, Arun Ganesh wrote:
On Sun, May 17, 2015 at 4:15 AM, Paul Norman penor...@mac.com
mailto: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 that this imagery is in Geographic Latlong (i.e.
EPSG:4326) and not in Web mercator
Those are standard map tiles, in Web Mercator.
You can compare http://tile.openstreetmap.org/10/719/456.png and
http://tile1.nrsc.gov.in/tilecache/tilecache.py/1.0.0/bhuvan_imagery2/10/719/456.jpg
to see that they are the same area.
Thanks Paul, after poking around stumbled on their full list of tile
layers:
http://tile1.nrsc.gov.in/tilecache/tilecache.py/1.0.0/layers
bhuvan_imagery is in WGS84
bhuvan_imagery2 is in web mercator
The tms url for bhuvan_imagery2:
tms:http://tile{switch:1,2,3,4}.nrsc.gov.in/tilecache/tilecache.py/1.0.0/bhuvan_imagery2/{zoom}/{x}/{y}.jpg
http://nrsc.gov.in/tilecache/tilecache.py/1.0.0/bhuvan_imagery2/%7Bzoom%7D/%7Bx%7D/%7By%7D.jpg
--
Arun Ganesh
(planemad) http://en.wikipedia.org/wiki/User:Planemad
http://j.mp/ArunGanesh
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in
--
Shekhar Krishnan
@bombayologist
http://shekhar.cc
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in
--
Sajjad Anwar http://geohacker.in
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Id editor on Bhuvan
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 they give an API service, wouldn't it be enough? We should be clear of exactly what to ask. Tiles are an API - you request z/x/y and get back an image for an area defined by z, x, and y. ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Id editor on Bhuvan
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 that this imagery is in Geographic Latlong (i.e. EPSG:4326)
and not in Web mercator
Those are standard map tiles, in Web Mercator.
You can compare http://tile.openstreetmap.org/10/719/456.png and
http://tile1.nrsc.gov.in/tilecache/tilecache.py/1.0.0/bhuvan_imagery2/10/719/456.jpg
to see that they are the same area.
Thanks Paul, after poking around stumbled on their full list of tile layers:
http://tile1.nrsc.gov.in/tilecache/tilecache.py/1.0.0/layers
bhuvan_imagery is in WGS84
bhuvan_imagery2 is in web mercator
The tms url for bhuvan_imagery2:
tms:http://tile{switch:1,2,3,4}.
nrsc.gov.in/tilecache/tilecache.py/1.0.0/bhuvan_imagery2/{zoom}/{x}/{y}.jpg
http://nrsc.gov.in/tilecache/tilecache.py/1.0.0/bhuvan_imagery2/%7Bzoom%7D/%7Bx%7D/%7By%7D.jpg
--
Arun Ganesh
(planemad) http://en.wikipedia.org/wiki/User:Planemad
http://j.mp/ArunGanesh
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Id editor on Bhuvan
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. There are quite a few Bhuvan layers that are not. There's two sides to this - one is getting the imagery, the other is having it hosted somewhere. If you can get the imagery under a usable license, I'm sure someone can host it. Once it's hosted, it can be added to the list for iD and P2 (https://github.com/osmlab/editor-imagery-index) and to the JOSM wiki (http://josm.openstreetmap.de/wiki/Maps) ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in Do we really need the tiles? If they give an API service, wouldn't it be enough? We should be clear of exactly what to ask. GN -- GN ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Id editor on Bhuvan
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 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. There are quite a few Bhuvan layers that are not. There's two sides to this - one is getting the imagery, the other is having it hosted somewhere. If you can get the imagery under a usable license, I'm sure someone can host it. Once it's hosted, it can be added to the list for iD and P2 (https://github.com/osmlab/editor-imagery-index) and to the JOSM wiki (http://josm.openstreetmap.de/wiki/Maps) -- Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in Do we really need the tiles? If they give an API service, wouldn't it be enough? We should be clear of exactly what to ask. GN -- GN ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Id editor on Bhuvan
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: https://cloud.githubusercontent.com/assets/126868/7664965/eb3e1326-fbbf-11e4-8792-1d605a28c659.png This is available from the 'Create a map/GIS' link from the homepage http://bhuvan.nrsc.gov.in User registration required. Most contributions seem to be in New Delhi https://cloud.githubusercontent.com/assets/126868/7664977/a8736946-fbc0-11e4-969f-2c81b4e7447e.png A few in Mumbai: https://cloud.githubusercontent.com/assets/126868/7664989/1ba0358e-fbc1-11e4-900e-0394e839eeac.png Not much activity in other major cities. -- Arun Ganesh (planemad) http://en.wikipedia.org/wiki/User:Planemad http://j.mp/ArunGanesh ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Id editor on Bhuvan
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 not bothered about licensing terms, since these satellites were launched with public money, and by right their output is public. :-) S.K. -- Shekhar Krishnan @bombayologist http://shekhar.cc On 16-May-2015 11:03 am, Sajjad Anwar m...@sajjad.in wrote: 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 available for outside the ecosystem. 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 satellite maps from Bhuvan/ISRO, what do we need from them? Do they have an API to pull them as background maps? We may need them mostly while editing. Since Id editor is already used by them, I am wondering they may already be using OSM software stack. 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. Was there any history of osm community seeking data from ISRO? Recently, we got in touch with ISRO for high resolution post earthquake imagery for Nepal. They shared the raw data and some of us at Mapbox processed it to make it available on OpenStreetMap - https://twitter.com/geohacker/status/593114332164001792 Sajjad. ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Id editor on Bhuvan
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 data. GN and I want to do this via TIFR, we could also work with Mapbox India. I'm not bothered about licensing terms, since these satellites were launched with public money, and by right their output is public. :-) Agree Shekhar. Just that we'll need this in writing to use with OpenStreetMap :) S.K. -- Shekhar Krishnan @bombayologist http://shekhar.cc On 16-May-2015 11:03 am, Sajjad Anwar m...@sajjad.in wrote: 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 available for outside the ecosystem. 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 satellite maps from Bhuvan/ISRO, what do we need from them? Do they have an API to pull them as background maps? We may need them mostly while editing. Since Id editor is already used by them, I am wondering they may already be using OSM software stack. 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. Was there any history of osm community seeking data from ISRO? Recently, we got in touch with ISRO for high resolution post earthquake imagery for Nepal. They shared the raw data and some of us at Mapbox processed it to make it available on OpenStreetMap - https://twitter.com/geohacker/status/593114332164001792 Sajjad. ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in -- Sajjad Anwar http://geohacker.in ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Id editor on Bhuvan
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 - http://blogs.bing.com/maps/2010/11/23/bing-engages-open-maps-community/ And OSM blog - https://blog.openstreetmap.org/2010/11/30/microsoft-imagery-details/ ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Id editor on Bhuvan
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: http://tile5.nrsc.gov.in/tilecache/tilecache.py?LAYERS=bhuvan_imagerySERVICE=WMSVERSION=1.1.1REQUEST=GetMapSTYLES=FORMAT=image%2FjpegSRS=EPSG%3A4326BBOX=95.625,22.5,98.4375,25.3125WIDTH=256HEIGHT=256 On Sat, May 16, 2015 at 11:57 AM, Sajjad Anwar m...@sajjad.in wrote: 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 data. GN and I want to do this via TIFR, we could also work with Mapbox India. I'm not bothered about licensing terms, since these satellites were launched with public money, and by right their output is public. :-) Agree Shekhar. Just that we'll need this in writing to use with OpenStreetMap :) S.K. -- Shekhar Krishnan @bombayologist http://shekhar.cc On 16-May-2015 11:03 am, Sajjad Anwar m...@sajjad.in wrote: 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 available for outside the ecosystem. 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 satellite maps from Bhuvan/ISRO, what do we need from them? Do they have an API to pull them as background maps? We may need them mostly while editing. Since Id editor is already used by them, I am wondering they may already be using OSM software stack. 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. Was there any history of osm community seeking data from ISRO? Recently, we got in touch with ISRO for high resolution post earthquake imagery for Nepal. They shared the raw data and some of us at Mapbox processed it to make it available on OpenStreetMap - https://twitter.com/geohacker/status/593114332164001792 Sajjad. ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in -- Sajjad Anwar http://geohacker.in ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in -- Arun Ganesh (planemad) http://en.wikipedia.org/wiki/User:Planemad http://j.mp/ArunGanesh ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Id editor on Bhuvan
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 to this - one is getting the imagery, the other is having it hosted somewhere. If you can get the imagery under a usable license, I'm sure someone can host it. Once it's hosted, it can be added to the list for iD and P2 (https://github.com/osmlab/editor-imagery-index) and to the JOSM wiki (http://josm.openstreetmap.de/wiki/Maps) ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Id editor on Bhuvan
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 mercator Those are standard map tiles, in Web Mercator. You can compare http://tile.openstreetmap.org/10/719/456.png and http://tile1.nrsc.gov.in/tilecache/tilecache.py/1.0.0/bhuvan_imagery2/10/719/456.jpg to see that they are the same area. ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Id editor on Bhuvan
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 maps from ISRO for school and college mapping projects that we are currently doing. If openstreetmap.in would like to get the satellite maps from Bhuvan/ISRO, what do we need from them? Do they have an API to pull them as background maps? We may need them mostly while editing. Since Id editor is already used by them, I am wondering they may already be using OSM software stack. Was there any history of osm community seeking data from ISRO? suggestions and tips welcome! -- GN ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
[Talk-in] Id editor on Bhuvan
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 satellite maps from Bhuvan/ISRO, what do we need from them? Do they have an API to pull them as background maps? We may need them mostly while editing. Since Id editor is already used by them, I am wondering they may already be using OSM software stack. Was there any history of osm community seeking data from ISRO? suggestions and tips welcome! -- GN ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Id editor on Bhuvan
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 available for outside the ecosystem. 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 satellite maps from Bhuvan/ISRO, what do we need from them? Do they have an API to pull them as background maps? We may need them mostly while editing. Since Id editor is already used by them, I am wondering they may already be using OSM software stack. 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. Was there any history of osm community seeking data from ISRO? Recently, we got in touch with ISRO for high resolution post earthquake imagery for Nepal. They shared the raw data and some of us at Mapbox processed it to make it available on OpenStreetMap - https://twitter.com/geohacker/status/593114332164001792 Sajjad. ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
[Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
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 Bing aerial pokud je dostupný tak je mdlý a hlavně posunutý
(alespoň tam, kde jsem se v ČR díval).
Slušné letecké mapy jsou k dispozici u ČUZK. Například z WMS mapové
služby:
http://geoportal.cuzk.cz/WMS_ORTOFOTO_PUB/WMService.aspx?service=WMSrequest=getCapabilities
lze (technicky) (při vhodných volbách) získat mapové dlaždice ve stylu
OSM.
K dispozici je přímo i dlaždicová služba WMTS viz:
http://geoportal.cuzk.cz/WMTS_ORTOFOTO/WMTService.aspx?service=WMTSrequest=GetCapabilities
Ale ta kupodivu se jeví méně kvalitní než služba WMS a dokonce i
pomalejší a asi je i méně aktuální. Ve webovém editoru iD pokud zadám
mapový podklad Vlastní a vložím url:
http://geoportal.cuzk.cz/WMTS_ORTOFOTO_900913/service.svc/get?SERVICE=WMTSREQUEST=GetTileVERSION=1.0.0LAYER=ortoSTYLE=defaultTILEMATRIXSET=googlemapscompatibleext2:epsg:3857TILEMATRIX={z}TILECOL={x}TILEROW={y}FORMAT=image%2Fjpg
tak to funguje (někdy), ale velmi pomalu.
Mé dotazy:
Je možné (legální) využívat letecké mapy, které na uvedených službách
ČUZK poskytuje pro editaci OSM map?
Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD
editoru nabízena přímo ČUZK letecká mapa?
Existují nějaké další mapové podklady ČR a s nimi spojené služby, které
by se daly využít jako podklad pro editaci OSM map a které by bylo možné
přímo doplnit v iD editoru do výběru vrstev?
Mít kvalitní podklad pro editaci map OSM na území ČR přímo ve webovém iD
editoru by bylo úžasné...
Zdraví
Marek Chlup
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
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 Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD editoru nabízena přímo ČUZK letecká mapa? Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM. Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu konference. HTH, Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
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 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 pročítal, ale kolize s licencí ODbL se mi těžko posuzují (přiznám se, že i ODbL nechápu detailně)... Každopádně děkuji za odkaz na wiki. Díval jsem se zejména na WMS katastrální mapy, které jsou hodnoceny jako zdroj dat v pořádku. Na některé záležitosti jde i o lepší zdroj než ORTOFOTO. Tedy velmi bych přivítal, kdyby bylo možné v iD editoru na openstreetmap.org vybrat přímo vrstvu ČÚZK Katastrální mapy. Kam se s takovou prosbou dá vhodně obrátit (aby to bylo zakomponováno do nabídky iD editoru)? Zdraví Marek Chlup On Mon, Jan 13, 2014 at 03:42:51PM +0100, Libor Pechacek wrote: 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 Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD editoru nabízena přímo ČUZK letecká mapa? Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM. Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu konference. HTH, Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
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 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 pročítal, ale kolize s licencí ODbL se mi těžko posuzují (přiznám se, že i ODbL nechápu detailně)... Každopádně děkuji za odkaz na wiki. Díval jsem se zejména na WMS katastrální mapy, které jsou hodnoceny jako zdroj dat v pořádku. Na některé záležitosti jde i o lepší zdroj než ORTOFOTO. Tedy velmi bych přivítal, kdyby bylo možné v iD editoru na openstreetmap.org vybrat přímo vrstvu ČÚZK Katastrální mapy. Kam se s takovou prosbou dá vhodně obrátit (aby to bylo zakomponováno do nabídky iD editoru)? Zdraví Marek Chlup On Mon, Jan 13, 2014 at 03:42:51PM +0100, Libor Pechacek wrote: 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 Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD editoru nabízena přímo ČUZK letecká mapa? Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM. Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu konference. HTH, Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
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: 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 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 pročítal, ale kolize s licencí ODbL se mi těžko posuzují (přiznám se, že i ODbL nechápu detailně)... Každopádně děkuji za odkaz na wiki. Díval jsem se zejména na WMS katastrální mapy, které jsou hodnoceny jako zdroj dat v pořádku. Na některé záležitosti jde i o lepší zdroj než ORTOFOTO. Tedy velmi bych přivítal, kdyby bylo možné v iD editoru na openstreetmap.org vybrat přímo vrstvu ČÚZK Katastrální mapy. Kam se s takovou prosbou dá vhodně obrátit (aby to bylo zakomponováno do nabídky iD editoru)? Zdraví Marek Chlup On Mon, Jan 13, 2014 at 03:42:51PM +0100, Libor Pechacek wrote: 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 Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD editoru nabízena přímo ČUZK letecká mapa? Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM. Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu konference. HTH, Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz; ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
Aha, nojo, teď koukám, že iD nepodporuje WMS zdroje (umí zatím jen TMS a
Bing), takže proto to KM nenabízí.
Než to někdo vyřeší (https://github.com/openstreetmap/iD/issues/1141), tak
to lze řešit prostřednictvím proxy (http://whoots.mapwarper.net/).
Stačí zvolit v iD vlastní pozadí a zadat tam např.
http://whoots.mapwarper.net:80/tms/{z}/{x}/{y}/parcelni_cisla,obrazy_parcel,
RST_KMD,hranice_parcel,DEF_BUDOVY,RST_KN,dalsi_p_mapy,prehledka_kat_prac,
prehledka_kat_uz,prehledka_kraju-linie/http://services.cuzk.cz/wms/wms.asp
Honza
-- 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
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:
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 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 pročítal, ale kolize s licencí ODbL se mi těžko
posuzují (přiznám se, že i ODbL nechápu detailně)...
Každopádně děkuji za odkaz na wiki. Díval jsem se zejména na WMS
katastrální mapy, které jsou hodnoceny jako zdroj dat v pořádku. Na
některé záležitosti jde i o lepší zdroj než ORTOFOTO. Tedy velmi bych
přivítal, kdyby bylo možné v iD editoru na openstreetmap.org vybrat
přímo vrstvu ČÚZK Katastrální mapy. Kam se s takovou prosbou dá vhodně
obrátit (aby to bylo zakomponováno do nabídky iD editoru)?
Zdraví
Marek Chlup
On Mon, Jan 13, 2014 at 03:42:51PM +0100, Libor Pechacek wrote:
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
Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém
iD
editoru nabízena přímo ČUZK letecká mapa?
Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM.
Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu
konference.
HTH,
Libor
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz;
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz;___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
Děkuji. S tím proxy to funguje.
Takže zřejmě až bude iD umět WMS zdroje tak asi do nabídky mapových
podkladů spadne výběr katastrálních map automaticky.
Mimochodem help v iD zřejmě předběhl dobu jelikož v sekci helpu
Podkladové snímky je text:
... Pro velkou část České republiky jsou také dostupné velmi detailní
satelitní snímky a navíc data z katastru nemovitostí.
iD mne každopádně fascinuje co vše je již možné v prohlížeči čistě na
bázi HTML/JavaScript realizovat (až na tu pomalost na Atom je super).
Marek
On Mon, Jan 13, 2014 at 09:52:00PM +0100, Jan Vršovský wrote:
Aha, nojo, teď koukám, že iD nepodporuje WMS zdroje (umí zatím jen TMS a
Bing), takže proto to KM nenabízí.
Než to někdo vyřeší (https://github.com/openstreetmap/iD/issues/1141), tak
to lze řešit prostřednictvím proxy (http://whoots.mapwarper.net/).
Stačí zvolit v iD vlastní pozadí a zadat tam např.
http://whoots.mapwarper.net:80/tms/{z}/{x}/{y}/parcelni_cisla,obrazy_parcel,
RST_KMD,hranice_parcel,DEF_BUDOVY,RST_KN,dalsi_p_mapy,prehledka_kat_prac,
prehledka_kat_uz,prehledka_kraju-linie/http://services.cuzk.cz/wms/wms.asp
Honza
-- 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
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:
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 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 pročítal, ale kolize s licencí ODbL se mi těžko
posuzují (přiznám se, že i ODbL nechápu detailně)...
Každopádně děkuji za odkaz na wiki. Díval jsem se zejména na WMS
katastrální mapy, které jsou hodnoceny jako zdroj dat v pořádku. Na
některé záležitosti jde i o lepší zdroj než ORTOFOTO. Tedy velmi bych
přivítal, kdyby bylo možné v iD editoru na openstreetmap.org vybrat
přímo vrstvu ČÚZK Katastrální mapy. Kam se s takovou prosbou dá vhodně
obrátit (aby to bylo zakomponováno do nabídky iD editoru)?
Zdraví
Marek Chlup
On Mon, Jan 13, 2014 at 03:42:51PM +0100, Libor Pechacek wrote:
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
Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém
iD
editoru nabízena přímo ČUZK letecká mapa?
Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM.
Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu
konference.
HTH,
Libor
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz;
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz;
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] id editor
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 22:41, Etienne Trimaille etienne.trimai...@gmail.coma écrit : 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 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 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 -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] id editor
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. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] id editor
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 pas comment un multipolygone se retrouve ainsi modifié vu l'interface limitée d'iD vis à vis des relations... Le 10 septembre 2013 22:41, Etienne Trimaille etienne.trimai...@gmail.com a écrit : 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 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 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 -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ 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
[OSM-talk-fr] id editor
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 mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] id editor
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 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 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-TW] iD editor 翻譯
我在那上面看到兩位幫忙翻譯的朋友，分別是 hlaw 、 xavier114fch。 有寫信跟兩位聯繫，其中來自香港的 hlaw 有回應 (上個月了, sorry)，他的意思是：main branch的譯文，應純為翻譯，因此在翻譯時維持了通用性，即使是台灣用戶，也可編輯其他地方的道路。因此套用地區性的 tagging 標準於編輯器中也許未必合適。 李昕迪 Lee, Sin-di mcd...@gmail.com 於 2013年5月11日下午9:47 寫道： 我的想法是 iD 如果設定是門檻比較低的編輯器，是不是給新手的障礙可以降低到不必一定要去看 Taiwan tagging 。 Dennis Raylin Chen b92612...@gmail.com 於 2013年5月11日下午9:00 寫道： 這有個問題，像烏來那邊孝義產業道路， 是台9甲，但道路品質很低的 2013/5/11 李昕迪 Lee, Sin-di mcd...@gmail.com https://www.transifex.com/projects/p/id-editor/ 有一點想提出來討論一下，既然已經是 Chinese (Taiwan)了， Primary road, Secondary road, Tertiary road 這些詞彙是不是直接翻為「省道」、「縣道」和「鄉道」會更好呢？ -- 李昕迪 Lee, Sin-di | http://www.mcdlee.tw ___ Talk-TW mailing list Talk-TW@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-tw -- 李昕迪 Lee, Sin-di | http://www.mcdlee.tw -- 李昕迪 Lee, Sin-di | http://www.mcdlee.tw ___ Talk-TW mailing list Talk-TW@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-tw
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 es sinnvoll: jeweils up, down, high,low oder inside, outside als Wertpaare zu verwenden. Natürlich ist eigentlich nur jeweils ein Zusatztag wirklich nötig. Beispiel Tagging: natural=cliff cliff:left=up (cliff:right=down) Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 inside/outside sinnvoll ist, weiß ich nicht - aber wenn wir dabei von Polygonen sprechen, dann ist deren Richtung bei uns nicht definiert (die Nodes können also sowohl im als auch gegen den Uhrzeigersinn angeordnet sein im geschlossenen way). Insofern ist inside/outside nichts, was sich in diesem Fall auf das Umkehren eines ways auswirken dürfte. Oder sehe ich hier die Tags nicht, die dir abei vorschweben? Gruß Peter Am 16.05.2013 09:56, schrieb Simon Poole: 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 es sinnvoll: jeweils up, down, high,low oder inside, outside als Wertpaare zu verwenden. Natürlich ist eigentlich nur jeweils ein Zusatztag wirklich nötig. Beispiel Tagging: natural=cliff cliff:left=up (cliff:right=down) Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 Stadtmauern heute noch so durchgängig sein dürften, dass sie als Polygone mit entrance-nodes gemappt werden könnten. Gruß Peter Am 16.05.2013 10:36, schrieb Simon Poole: 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 klares innen und aussen, wäre also einfacher zum Taggen. Die Diskussion driftet aber jetzt doch -sehr- ab, die genaue Semantik der Tags im einzelnen ist ja auch nicht das Thema. Simon Am 16.05.2013 10:53, schrieb Peter Wendorff: 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 Stadtmauern heute noch so durchgängig sein dürften, dass sie als Polygone mit entrance-nodes gemappt werden könnten. Gruß Peter Am 16.05.2013 10:36, schrieb Simon Poole: 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 inside, outside als Wertpaare zu verwenden. Natürlich ist eigentlich nur jeweils ein Zusatztag wirklich nötig. Mit Zusatztags, die die Bedeutung von Tags verändern, machen aber alte Programme Ärger, da sie die Richtungstags ignorieren werden. Das bringt die Mapper dazu, lustige Taggingideen auszuprobieren. Außerdem sollten die Zusatztags ja immer vorhanden sein, damit die Sache für die Mapper klarer wird. Aus Kompatibilitätsgründen müsste man aber den jetzigen Zustand zum Default erklären. Dann werden ihn aber viele weglassen. Das Problem könnte man aber mit einem Stichtag und einem Bot lösen. Auch wenn es hässlich ist: ein natural=cliff2 mit cliff2:left=high würde Probleme vermeiden. Na ja, vielleicht wäre natural=edge oder natural=slope oder noch was anderes besser. (Bei coastline hätte man die Gelegenheit, endlich das Wort ocean im Tag unterzubringen -- das würde viele Reparaturarbeiten in Seen und Flüssen einsparen.) Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 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 klares innen und aussen, wäre also einfacher zum Taggen. Die Diskussion driftet aber jetzt doch -sehr- ab, die genaue Semantik der Tags im einzelnen ist ja auch nicht das Thema. Simon Am 16.05.2013 10:53, schrieb Peter Wendorff: 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 Stadtmauern heute noch so durchgängig sein dürften, dass sie als Polygone mit entrance-nodes gemappt werden könnten. Gruß Peter Am 16.05.2013 10:36, schrieb Simon Poole: 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 Seiten- bzw. Richtungsangaben in den Schlüssel zu nehmen macht genau dann Sinn, wenn man beides gleichzeitig verwenden können soll (etwa bei zwei Gehsteigen links und rechts, die unterschiedliche surface-Werte bekommen). Das ist hier aber nicht gewollt - bestenfalls ist es redundant wie dein Tag in Klammern, eventuell sogar widersprüchlich. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 nicht richtig. in dem ursprünglichen Proposal zu barrier (wo city_wall enthalten war), waren Stadtmauern bereits als zweiseitig definiert, was ja auch Sinn macht. Das Innen wird wohl praktisch immer oder jedenfalls sehr oft anders ausfallen als die nach aussen gewandte Seite (innen hat man normalerweise Gänge und Räume, wo die Verteidiger sich bewegen, aussen hat man oft geneigte Mauern an der Basis, Schießscharten, etc.). Allerdings ist das ein relativ grobes Modell, wo die gesamte Stadtmauer als ein linearer Weg beschrieben ist, während bei genauerem Mapping ja auch die Wege in und hinter der Mauer, sowie die Türme etc. gemappt werden, woraus sich eigentlich ergibt, dass man die Stadtmauer eher als Fläche mappen sollte, wenn man Lust hat. Dieses two-sided=yes macht dagegen m.E. weniger Sinn , den könnte ich nur da erkennen, wo auf beiden Seiten innen ist (also bei einer Mauer, die quer durch die Stadt läuft, und daraus sozusagen 2 Städte oder Hälften macht). Nur an der Höhe eine Gleichheit der Innen- und Aussenseite zu postulieren ist ein bisschen kurz gesprungen (s.o.). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 auch flow = forward/backward/(alternating) Die Seiten- bzw. Richtungsangaben in den Schlüssel zu nehmen macht genau dann Sinn, wenn man beides gleichzeitig verwenden können soll (etwa bei zwei Gehsteigen links und rechts, die unterschiedliche surface-Werte bekommen). Das ist hier aber nicht gewollt - bestenfalls ist es redundant wie dein Tag in Klammern, eventuell sogar widersprüchlich. 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. Deine Beispiele lassen widersprüchliche Werte dann auch noch zu (cliff:lower_side=left, cliff:upper_side=left). Ich würde deshalb wenn schon dann eher etwas in der Art wie cliff=lower:left verwenden (auch dies würde aber von den Editoren Unterstützung verlangen). Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 Grund, warum nicht auch hier left/right genutzt werden sollte; zumal die wenigsten Stadtmauern heute noch so durchgängig sein dürften, dass sie als Polygone mit entrance-nodes gemappt werden könnten. es geht dabei z.B. darum, dass man auch bei einem Fragment erkennen kann, wo mal innen und aussen war. Ein Damm wie eine Stadtmauer hat üblicherweise 2 unterschiedliche Seiten, innen und aussen, von daher passt inside/outside prinzipiell gut finde ich. Das ist unabhängig davon, ob die Stadtmauer nun aktuell vor dem Eindringen von Feinden schützen soll, oder nur noch Relikt ist und keine Tore mehr geschlossen werden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 Spickermann: Hi, Am Thu, 16 May 2013 09:56:57 +0200 Mit Zusatztags, die die Bedeutung von Tags verändern, machen aber alte Programme Ärger, da sie die Richtungstags ignorieren werden. Das bringt die Mapper dazu, lustige Taggingideen auszuprobieren. Außerdem sollten die Zusatztags ja immer vorhanden sein, damit die Sache für die Mapper klarer wird. Aus Kompatibilitätsgründen müsste man aber den jetzigen Zustand zum Default erklären. Dann werden ihn aber viele weglassen. Das Problem könnte man aber mit einem Stichtag und einem Bot lösen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 zumindest bei JOSM wird beim Umdrehen aus irgendwas=forward ein irgendwas=backward, und aus irgendwas=left ein irgendwas=right. Das ist auch nötig, denn es gibt bereits solche Fälle, zB für Gehsteige sidewalk = left/right/both oder für Rolltreppen: conveying = forward/backward/reversible Deine Beispiele lassen widersprüchliche Werte dann auch noch zu (cliff:lower_side=left, cliff:upper_side=left). Nein, da es keinen Schlüssel cliff:upper_side geben soll. Ich würde deshalb wenn schon dann eher etwas in der Art wie cliff=lower:left verwenden (auch dies würde aber von den Editoren Unterstützung verlangen). Das wäre aber wieder was neues, wohingegen left/right/forward/backward als Werte bereits in Gebrauch sind, siehe oben. Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 entsprechende Zusatztag setzen. Ich dachte mehr an die Probleme danach. Noch nicht umgestellte mkgmap Eingabedateien würden falsche Karten produzieren. Ein noch nicht umgestellter OSMI würde falsche Fehlermeldungen erzeugen. Noch nicht umgestellte Renderer würden Mapper zu unsinnigen Änderungen anregen. Die Probleme sind in diesem Fall nicht sooo gravierend. Aber sie sind ein Beispiel für die Probleme beim Umdefinieren von Tags. Jedes Umdefinieren von Tags entwertet die Tags oder bisher geleistete Arbeit in Programmen, Konfigurationsdateien oder beim Mappen. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 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 eine Abwägung, der status quo hat halt auch Probleme, die man vorher nicht vorhergesehen hatte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 machen muss, ob der Weg eine Richtung hat oder nicht. Vorallem auch vor dem Hintergrund, dass immer mehr Mapper mitmachen wollen, die sich nicht unbedingt in den Tiefen des Wikis schauen wollen, ob nun Coastline gerichtet ist (und was die Richtung bedeutet). Henning Am 16.05.2013 13:37, schrieb Martin Koppenhoefer: 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 eine Abwägung, der status quo hat halt auch Probleme, die man vorher nicht vorhergesehen hatte. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 eine Abwägung, der status quo hat halt auch Probleme, die man vorher nicht vorhergesehen hatte. Doch, sowas kann man machen. Dazu braucht man die Möglichkeit anzugeben, auf welche Definition sich das Tagging bezieht (Normen). Etwa so: Nach Abstimmung eines Proposals wird dieses eingefroren (unveränderlich gemacht) und ihm wird zentral eine Nummer gegeben. Der Mapper kann (nicht: muss!) mit z.B. OSM_NORM=4711 darauf Bezug nehmen. Wird später ein Nachfolger verabschiedet, so erhält er eine neue Nummer. Man kann nun den alten Datensätzen ihre Bedeutung noch vollständig ansehen und sie auf die neue Form umstellen (oder sie so lassen). Man könnte auch alte Normen als deprecated deklarieren und damit zur Umstellung durch Bots oder Mapper auffordern. Verarbeitende Programme wüssten dann, was sie verarbeiten können und was nicht. Für die Editoren/Inspektoren könnte das die Prüfung auf Fehler enorm verbessern, da sie einen ganze Sätze von Prüfungen anhand der Nummern in OSM_NORM=x;y;z aktivieren könnten und nicht auf die kleinsten gemeinsamen Eigenschaften beschränkt wären. Ich denke, dass solche Normen große Vorteile mit sich bringen würden. Allerdings auch die Möglichkeit, dass Verbesserungen immer nur als zusätzliche Möglichkeiten aufgefasst würden. Da müssten wir überlegen, mit welchen sozialverträglichen Vorgehensweisen man Ausufern verhindern kann. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 weisen ist, aber es ist eine Abwägung, der status quo hat halt auch Probleme, die man vorher nicht vorhergesehen hatte. Doch, sowas kann man machen. Dazu braucht man die Möglichkeit anzugeben, auf welche Definition sich das Tagging bezieht (Normen). 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 diese auch nicht erlangen. -- Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 diese auch nicht erlangen. Daran würde sich durch den Vorschlag auch nichts ändern. Es würde nur eine Nummer vergeben, die sich dann verbindlich auf diesen Vorschlag bezieht ... nicht mehr. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 vermutlich eher selten vorkommen, dass ein verantwortungsbewusster Anfänger Straßen(teile) löscht Ich hatte schon am 09.05.2013 23:12 Uhr ausführlich beschrieben, wie so etwas in gutem Glauben auch absichtlich passieren kann. (die Mitglieder von Relationen enthalten können) Dazu muss der Anfänger aber erst einmal von deren Existenz wissen. Und die ist in der Mapnik Standarddarstellung nicht zu sehen. Wenn dann auch der Editor nicht darauf hinweist ... Dazu kommt, dass auch in den Anleitungsvideos auf youtube von Steve Coast munter editiert wurde, ohne dass Relationen erwähnt wurden. Hätte er diese Edits mit Potlatch auf Wegen mit Relationen vorgenommen, dann wären diese anschließend zerstört gewesen. oder absichtlich die Richtung einer Einbahnstraße oder eines Wasserweges umkehrt. Aber unabsichtlich: Ich erinnere mich ganz dunkel: Zu Anfang habe ich weder Relationen noch Wege-Richtungen wahrgenommen und mich auf das massenweise Eintragen von Straßennamen beschränkt. Dazwischen begann ich, einige Icons zu probieren, wobei auch das erst später als Richtungsumkehr identifizierte Icon dabei war. Ich konnte aber keine Reaktion im Bild feststellen. Mag durchaus sein, dass bei der Probiererei eine Richtungsumkehr übrigblieb. Heute scheinen die Editoren Alles davon Abhängige selbstständig umzudrehen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 natürlich noch mehr geben) natural=cliff natural=coastline barrier=retaining_wall man_made=embankment Leider unvollständig und damit keiner sagt, dass er/sie es nicht gewußt hat. Hier die Doku. https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/corrector/ReverseWayNoTagCorrector.java?rev=5732#L27 https://josm.openstreetmap.de/ticket/4664 https://trac.openstreetmap.org/ticket/4787 Wobei man_made=embankment und barrier=city_wall mir auch neu sind. 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 non-stupid Alternative zu oneway=yes haette ich da aber schon gerne gehoert. Und ich würde gerne Deine Alternativen wissen bevor Du sie als deprecated markieren willst. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 nächsten Wochen ergeben. Alles beste, Alex https://github.com/systemed/iD/wiki/1.1-Roadmap 2013/5/15 fly lowfligh...@googlemail.com 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 natürlich noch mehr geben) natural=cliff natural=coastline barrier=retaining_wall man_made=embankment Leider unvollständig und damit keiner sagt, dass er/sie es nicht gewußt hat. Hier die Doku. https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/corrector/ReverseWayNoTagCorrector.java?rev=5732#L27 https://josm.openstreetmap.de/ticket/4664 https://trac.openstreetmap.org/ticket/4787 Wobei man_made=embankment und barrier=city_wall mir auch neu sind. 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 non-stupid Alternative zu oneway=yes haette ich da aber schon gerne gehoert. Und ich würde gerne Deine Alternativen wissen bevor Du sie als deprecated markieren willst. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 https://github.com/systemed/iD/issues 2013/5/15 Alex Barth a...@mapbox.com 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 nächsten Wochen ergeben. Alles beste, Alex https://github.com/systemed/iD/wiki/1.1-Roadmap 2013/5/15 fly lowfligh...@googlemail.com 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 natürlich noch mehr geben) natural=cliff natural=coastline barrier=retaining_wall man_made=embankment Leider unvollständig und damit keiner sagt, dass er/sie es nicht gewußt hat. Hier die Doku. https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/corrector/ReverseWayNoTagCorrector.java?rev=5732#L27 https://josm.openstreetmap.de/ticket/4664 https://trac.openstreetmap.org/ticket/4787 Wobei man_made=embankment und barrier=city_wall mir auch neu sind. 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 non-stupid Alternative zu oneway=yes haette ich da aber schon gerne gehoert. Und ich würde gerne Deine Alternativen wissen bevor Du sie als deprecated markieren willst. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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. Henning Am 14.05.2013 07:38, schrieb Wilhelm Spickermann: Hi, Ergänzung: Beim Splitten in sich geschlossener Linien mit Flächentag wird beim Splitten völlig richtig ein Multipolygon erzeugt und die Fläche bleibt erhalten. Das ist deutlich besser als beim JOSM. Wow. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Ü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 zu 100% korrekt sind. Ich könnte etwas kaputt machen, deshalb fasse ich lieber nichts an. Nicht zu erwähnen die Verärgerung erfahrener Mapper, die denken natürlich möchte ich den Weg umkehren und weiter klicken, ohne die Warnung zu lesen. Glücklicherweise macht vorsichtiges Design Benutzer sicherer und es weniger wahrscheinlich, dass etwas kaputt geht. Der beste Weg dies zu erreichen ist ihnen zu zeigen - ohne dass sie sich ein tiefes Verständnis der Datenstrukturen von OSM aneignen müssen - was sich auf der Karte befindet und welche Änderungen die vornehmen. Wir planen für natural=coastline eine Darstellung, die die Wasser- und Landseite¹ eindeutig zeigt und können das Gleiche für Klippen, Böschungen und Barrieren machen. Wasserwege und Einbahnstraßen haben bereits eine eindeutige Richtungsanzeige. Diese Ansicht finde ich durchaus nachvollziehbar. Allerdings muss man halt doch bei gewissem Zerstoerungspotential eine Abwaegung zwischen Neunutzerverschreckung und Datensicherheit vornehmen. Wenn richtungsabhaengige Tags sehr deutlich als solche gerendert werden, mildert das die Gefahr tatsaechlich ab. Allerdings muss man dann konsequent sein und auf Warnungen zurueckgreifen solange dieses Rendering noch nicht inplementiert ist. Werden diese Tags denn schon entsprechend gerendert? Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 das Erzeugen des MP überflüssig. OK. Hmmm. Ist hab's nicht ausprobiert: vielleicht verschwindet das MP sogar automatisch wieder, wenn es nur noch ein Element hat? Ich finde aber, dass die Vorteile überwiegen. Vermutlich aber wohl deshalb, weil ich viele solche kaputtgesplitteten Flächen repariere. :-) Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 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. OK. Hmmm. Ist hab's nicht ausprobiert: vielleicht verschwindet das MP sogar automatisch wieder, wenn es nur noch ein Element hat? Ich finde aber, dass die Vorteile überwiegen. Vermutlich aber wohl deshalb, weil ich viele solche kaputtgesplitteten Flächen repariere. :-) Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 Rückfragen: beim Splitten: Der aufzutrennende Weg beschreibt eine Fläche. Was soll mit ihr geschehen? a) Fläche beibehalten durch Erzeugen eines Multipolygons. b) Fläche löschen c) nur die Linie auftrennen. und beim Combine: Die Fläche könnte jetzt auch ohne ein Multipolygon formuliert werden. a) Ja, die Fläche ohne Multipolygon formulieren. b) Nein. Nur die Linien verbinden. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 Warnung...dann gehen nicht die vorhandenen Daten kaputt. Ich würde preferieren wenn wir mal alle fälle sammeln die iD kaputt macht und warum. Und dann kann man die mal kategorisieren in - 1) Laesst sich technisch lösen 2) Muss man mit einem WARNING ausruesten. Ich denke das _viele_ dinge die hier genannt werden sich mit kleinigkeiten fixen lassen. Wegrichtungsumkehr ist eines davon - das ist wirklich Kindergeburtstag. 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. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 schon zugesichert, für die richtungsabhängigen Objekte eine entsprechende Darstellung einzubauen, so dass die Leute das nicht versehentlich sondern nur absichtlich ändern. Anderes aber ist problematischer (Nicht-Zeigen von Relationen und deren tags, Nicht-zeigen von tags, für die es einen Preset bzw. eine Übersetzung gibt). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 code einbauen der das verhindert. Sehe ich auch so, die Programmierer haben schon zugesichert, für die richtungsabhängigen Objekte eine entsprechende Darstellung einzubauen, so dass die Leute das nicht versehentlich sondern nur absichtlich ändern. Anderes aber ist problematischer (Nicht-Zeigen von Relationen und deren tags, Nicht-zeigen von tags, für die es einen Preset bzw. eine Übersetzung gibt). 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 könnte jetzt immer so weiter gehen, dann haben wir 10, 20, ... 1000 und mehr Ausnahmen. Wie 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. oneway=forward/backward coastline=yes sea=right/left Bestehende Software kann sehr leicht das neue Tagging einlesen und ggf. die Linie intern umdrehen, wenn das für die Verarbeitung nach dem bisherigen Tagging erforderlich ist. _NOCH_ sind es nur vier oder fünf tags. Mit dem Kliff könnte man auch downside=right oder so was machen. Auch für die anderen tags ginge das mit etwas gutem Willen. Für eine Übergangszeit gibt es dann beides, und danach werden alle tags selbsterklärend, ohne dass jeder Auswerter erst mal tausend Wiki-Beiträge durchackern muss, bis er versteht, was warum in welcher Richtung ausgewertet werden soll. Und beim mappen werden Fehler vermieden. Wäre auch die nonstupid-Alternative für oneway ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 darin, dass man auch angeben kann, dass man keine Ahnung hat, in welche Richtung das Objekt nun gerichtet ist. Bspw. bei einem Fluss, der auf dem Luftbild nur teilweise zu sehen ist. Viele Grüße Henning Am 14.05.2013 13:21, schrieb Wolfgang Hinsch: 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 könnte jetzt immer so weiter gehen, dann haben wir 10, 20, ... 1000 und mehr Ausnahmen. Wie 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. oneway=forward/backward coastline=yes sea=right/left Bestehende Software kann sehr leicht das neue Tagging einlesen und ggf. die Linie intern umdrehen, wenn das für die Verarbeitung nach dem bisherigen Tagging erforderlich ist. _NOCH_ sind es nur vier oder fünf tags. Mit dem Kliff könnte man auch downside=right oder so was machen. Auch für die anderen tags ginge das mit etwas gutem Willen. Für eine Übergangszeit gibt es dann beides, und danach werden alle tags selbsterklärend, ohne dass jeder Auswerter erst mal tausend Wiki-Beiträge durchackern muss, bis er versteht, was warum in welcher Richtung ausgewertet werden soll. Und beim mappen werden Fehler vermieden. Wäre auch die nonstupid-Alternative für oneway ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 Tagging einlesen und ggf. die Linie intern umdrehen, wenn das für die Verarbeitung nach dem bisherigen Tagging erforderlich ist. _NOCH_ sind es nur vier oder fünf tags. Mit dem Kliff könnte man auch downside=right oder so was machen. ja, das wäre im Prinzip eine gute Lösung, weil dann automatisch anpassbar bei Richtungsänderungen. So was hat man ja z.B. auch bei Treppen (highway=steps) schon gemacht mit dem incline-tag. Nachteil ist eigentlich nur, dass es schon viele anders getaggte Objekte gibt, und dass man zusätzliche tags braucht, für was bisher implizit war (dafür wird das dann auch explizit und springt daher eher ins Auge). Gruß Martin PS: Zur Liste der 5 tags kommt ggf. auch noch historic=citywalls (neben barrier gibt es auch dieses Tagging für Stadtmauern). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 könnte jetzt immer so weiter gehen, dann haben wir 10, 20, ... 1000 und mehr Ausnahmen. Wie 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. oneway=forward/backward coastline=yes sea=right/left +1 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 bin ja eher fuer im tag nicht in der value unterbringen - Aber das ist geschmacksfrage: oneway:forward=yes Wäre auch die nonstupid-Alternative für oneway ;-) Aber auch fuer 30 anwendungsfaelle ist das ja kein problem da eine zeile code einzufuegen ... Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 verändern. Ich stelle mir die Warnmeldung in etwa so vor (die verschiedenen Werte in [ ] müssen dann je nach Fall verwendet werden): Du bist dabei eine[n] [Punkt/Linie/Fläche] zu löschen, welche[r] Teil einer Ralation ist. Eine Relation ist eine Art Gruppierung von mehreren Elementen. In diesem Fall handelt es sich um eine[n] [Busroute/Wanderroute/Fahrradroute/Teil einer Fläche/Verkehrsüberwachungsanlage/Grenze/ÖPNV-Haltestelle/Regel, in welche Richtung man an dieser Kreuzung abbiegen darf]. Beim Löschen [des/der] [Punktes/Linie/Fläche]] wird er auch aus der Relation entfernt. Diese ist dann nicht mehr vollständig. Versuche falls möglich anstatt [den/die] [Punkt/Linie/Fläche] zu löschen [ihn/sie] entsprechend zu verändern oder zu verschieben. Weitere Informationen zu Relationen findest du im Wiki unter http://wiki.openstreetmap.org/wiki/Einf%C3%BChrung_Relationen. Gerne kannst du auch im Chat unter [direkter Link zum irc #osm-[ensprechende Sprache]] erfahrene Mapper um Hilfe bitten. Bist du sicher, dass du [den/die] [Punkt/Linie/Fläche] löschen willst? Was haltet ihr davon? Viele Grüße Stefan Am 13. Mai 2013 22:46 schrieb malenki o...@malenki.ch: Von dem Entwickler jfirebaugh gibt es jetzt auch eine wohl offizielle Antwort hinsichtlich richtungsabhängiger Tags/Wege: https://github.com/systemed/iD/issues/1475#issuecomment-17835596 | We're not planning to add any warnings for reversing ways. Warnings | may be well intentioned, but they run counter to iD's goal of | encouraging new users to contribute to the map because they make them | feel insecure, even when their edits are perfectly legitimate. I | might break something, I better not touch. Not to mention they are | an annoyance for experienced mappers, who think of course I want to | reverse it, and click through without reading. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 Diskussion zustande kam. Mit jfire war auch einer der Programmierer dabei. Er und auch iandees sind eher der Ansicht, dass Warnhinweise die User abschrecken und man solche Warnungen deshalb besser weglässt. Beim Umkehren von natural=coastline will jfire offenbar eine Schutzfunktion implementieren. Warnhinweise beim (versehentlichen) Umdrehen von Einbahnstraßen oder Wasserwegen scheinen dagegen nicht geplant oder erwünscht. Das Tastaturkürzel zum Umkehren der Wegrichtung ist V, das auf der Tastatur in der Regel neben B liegt - dem Kürzel für den Hintergrund - Luftbilder und Co. Relationen: Es ist geplant, Relationen gut sichtbar zu machen, damit die Nutzer sie wahrnehmen. Wenn dann ein Mitglied einer Abbiegebeschränkung gelöscht wird, soll die gesamte Relation entfernt werden. Was für ein Schwachsinn !! Hier haben wir nebenbei eine Relation, wo auch Punkte wichtig sind. Wer es genau nachlesen möchte, findet das IRC-Log hier: http://malenki.ch/OSM/irc_osm_-_id_reverse_ways_warn.txt hth Thomas Vielleicht werden die mehr fortgeschrittene Mapper ab jetzt alles doppeltredundant eintragen müssen. Eine Relation und dann noch welche Tags um an zu geben: hier gibt es eine Relation, wenn die Relation nicht mehr da ist, bitte neuerstellen. Schade das mit so wenig Respekt mit unsere Beitragen umgehen wird. +1 Gerade das Löschen und Revertieren ist sehr problematisch. Zusätzlich habe ich auch noch eine Aktion vergessen: Zusammenfügen und daraus entstehende Konflikte. Ich frage mich ja auch immer wieder warum solche Aktionen nicht verboten/verhindert werden, solange die Software zu doof dafür ist. Wie weit werden Newbies über die History von Objekten und die Richtungsbedeutungen aufgeklärt ? 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 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 fühlen. fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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: /** * 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 */ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 non-stupid Alternative zu oneway=yes haette ich da aber schon gerne gehoert. Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 true if somebody added the brain dead tags */ Deine non-stupid Alternative zu oneway=yes haette ich da aber schon gerne gehoert. 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 konnte, wie man es besser machen könnte (es gab ein paar Alternativvorschläge, die bisher als schlechter bewertet wurden). Neben den genannten oneway, retaining_wall und cliff sind das auch natural=coastline, alle forward- und backward-tags für Dinge, die nur in einer Richtung gelten, barrier=city_wall, left- und right-tags für Dinge, die einseitig vorkommen und implizit getaggt werden sollen (z.B. Fahrradwege), neuerdings wohl auch das lanes-Schema und vermutlich noch mehr. Diese tags führen keineswegs dazu, dass man die ways nicht umdrehen kann, man muss es nur mit Bedacht tun und ggf. weitere Dinge ändern, damit alles konsistent bleibt. Schwierig wird es m.E. vor allem dann, wenn nicht alle vorhandenen tags angezeigt werden, und div. Objekte (insb. Relationen) vor dem Nutzer versteckt werden. Das finde ich OK für einen einfachen POI-Editor, der dann aber auch nicht ermöglicht, diese Dinge kaputt zu machen. Wer Operationen erlaubt, die diese Dinge ggf. kaputtmachen können, der sollte auch soviel Vertrauen in die Fähigkeiten der Mapper haben, dass er ihnen eine Chance lässt, überhaupt zu erkennen, dass da noch mehr dran hängt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 man_made=embankment Simon Am 13.05.2013 14:43, schrieb Ronnie Soak: 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 non-stupid Alternative zu oneway=yes haette ich da aber schon gerne gehoert. Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 konnte, wie man es besser machen könnte (es gab ein paar Alternativvorschläge, die bisher als schlechter bewertet wurden). Neben den genannten oneway, retaining_wall und cliff sind das auch natural=coastline, alle forward- und backward-tags für Dinge, die nur in einer Richtung gelten, barrier=city_wall, left- und right-tags für Dinge, die einseitig vorkommen und implizit getaggt werden sollen (z.B. Fahrradwege), neuerdings wohl auch das lanes-Schema und vermutlich noch mehr. oneway, *:right, *:left, *:backward, *:forward, incline, direction, Himmelsrichtungen, Steigungen in °, Steigungen in % etc. sind alles vernünftig, wenn auch mit Aufwand, handhabbar. 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. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 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 man_made=embankment in dieser Liste auftaucht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 fühlen. +1 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 oneway=reverse) Gruss, Chaos Am 13. Mai 2013 16:10 schrieb Simon Poole si...@poole.ch: 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 man_made=embankment Simon Am 13.05.2013 14:43, schrieb Ronnie Soak: 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 non-stupid Alternative zu oneway=yes haette ich da aber schon gerne gehoert. Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 man_made=embankment in dieser Liste auftaucht. Siehe http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dembankment unter Usage Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 Cosdtlines fixen muss etc. was nur durch umdrehen möglich ist. Lg Ruben Am 13.05.2013 16:40 schrieb Martin Koppenhoefer dieterdre...@gmail.com: 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 mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
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. https://github.com/systemed/iD/blob/master/js/id/actions/reverse.js#L2-L4: Order the nodes of a way in reverse order and reverse any direction dependent tags other than `oneway`. (We assume that correcting a backwards oneway is the primary reason for reversing a way.) Hm... Ich glaube hier gibt es zwei verschiedene Interpretationen von Weg umkehren. Du meinst: Reihenfolge der Nodes im OSM-Way umkehren bei gleichzeitiger Beibehaltung des abgebildeten Sachverhalts. iD meint: Drehe die abgebildete Information 'Einbahnstraße' um. Ich glaube was iD macht, ist auch das was ein Einsteiger (der noch kein Verständnis der zugrundeliegenden Datenstrukturen hat) sich unter der Funktion erwartet. Ah, diese Einbahn ist falsch eingetragen. Um das zu berichtigen, muss ich den Weg umdrehen. Um weitere Verwirrung zu verhindern sollte die Funktion aber auch Einbahn umdrehen (reverse oneway) heißen und nur auf Einbahnstraßen angeboten werden. Für das Korrigieren der Richtung von Klippen, Dämmen, usw. könnte es dann eine eigene Aktion Richtung der Klippe umdrehen geben. Grüße Martin / tyr_asd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
