[Talk-hr] Pretvorbe podataka
Pozdrav, posložio sam automatsku pretvorbu OSM podataka u neke standardne GIS formate (SHP, sqlite i spatialite). Svaki dan će se generirati nove datoteke koje se mogu preuzeti s http://data.osm-hr.org/gis_exports/ Trenutno se radi export svega + specifično samo ceste (highway tag) za područje Hrvatske iz http://data.osm-hr.org/croatia.osm.pbf datoteke. Dakle, ako se ta datoteka ne osvježi neće se osvježivati niti /gis_export/. Osim toga pripremio sam i projekt za QGIS koji pokazuje primjer stilova za highways tag. Osim QGS projekta (http://data.osm-hr.org/gis_exports/highway_osm_croatia.qgs) treba vam datoteka http://data.osm-hr.org/gis_exports/highway_croatia.osm.spatial.sqlite , koju se mora nalaziti u istom direktoriju kao i QGIS projekt. Primam želje i ideje koje specifične tagove, za koja područja (unutar RH) želite da se automatski pripremaju. Moguće je i prirediti spremanje u neki drugi projekcijski sustav (trenutno je u izvornom WGS84 - ESPG:4326). Dražen ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
Treba smisliti i poster za SOTM ove godine. Pa da se predstavimo tamo. On 03.05.2013 21:17, hbogner wrote: Promotivni OSM letak Poziv svim zainteresiranim za pomoć. Treba nam ideja za dizajn promotivnog OSM letka koji bi predstavljao OSM globalno i hrvatsku OSM zajednicu i njezine aktivnosti. Tehničke specifikacije: dimenzije papira A6 jednostrano ili obostrano, margine minimalno 1cm zbog printa, crno bijeli dizajn, jezik letka hrvatski. Prva upotreba letka bi bila na DORS/CLUC 2013 tako da ga trebamo završiti nekoliko dana ranije. Svaka pomoć je dobrodošla. ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [OSM-talk-be] UrbIS - streetnumbers
2013/6/5 Pierre Parmentier pierrecparment...@gmail.com: Hi, We can observe that where 'UrbIS' shows sometimes multiple streetnumbers on a particular building way, 'CadGIS Viewer Grand Public' is quite better (and univocal). Thanks for giving the link to this CadGIS viewer that I did not know. You affirmation is strange to me. I thought that there was Urbis was the reference in Brussels and that is was used by the cadaster ! I have just checked on http://www.cirb.irisnet.be/fr/catalogue-de-services/urbis and I realize that there are different Urbis products. THe one that is referenced I suppose that UrbIS-Map is used on the link that Pierre gives, while UrbIS-PB is related to the cadaster data. There must be some good explanation why these sets of data are different, but I also wonder if it would not be interesting if they where only different views of the same datas. Has anyone more information about these ? This may be a question to ask to the person who will preent Urbis during the rmll http://schedule2013.rmll.info/programme/les-donnees-ouvertes/participation-citoyenne-et/article/donnees-urbis-brussels-donnees on Monday July 8 Regards, Nicolas -- Nicolas Pettiaux, dr. sc ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] UrbIS - streetnumbers
Hi everybody, I'm new to this and found your work, thumbs up guys :-) I recently tried to use the 1030.osm to add information for Schaarbeek in JOSM. I'm struggling a bit with the AssociatedStreet relations. Yesterday I added Rue Henri Evenepoel (Changeset: 16425586), could anybody please check if I added the information the right way? I woudn't want to continue adding wrong or incomplete information. Today I tried to add Place de la Patrie (Changeset 16434542) but I couldn't add both sides of the square to the same relation (probably because the square is just two one way roads?). Sorry to bother you guys with it, Cheers, FantAntonio On Wed, Jun 5, 2013 at 11:44 AM, Nicolas Pettiaux nico...@pettiaux.bewrote: 2013/6/5 Pierre Parmentier pierrecparment...@gmail.com: Hi, We can observe that where 'UrbIS' shows sometimes multiple streetnumbers on a particular building way, 'CadGIS Viewer Grand Public' is quite better (and univocal). Thanks for giving the link to this CadGIS viewer that I did not know. You affirmation is strange to me. I thought that there was Urbis was the reference in Brussels and that is was used by the cadaster ! I have just checked on http://www.cirb.irisnet.be/fr/catalogue-de-services/urbis and I realize that there are different Urbis products. THe one that is referenced I suppose that UrbIS-Map is used on the link that Pierre gives, while UrbIS-PB is related to the cadaster data. There must be some good explanation why these sets of data are different, but I also wonder if it would not be interesting if they where only different views of the same datas. Has anyone more information about these ? This may be a question to ask to the person who will preent Urbis during the rmll http://schedule2013.rmll.info/programme/les-donnees-ouvertes/participation-citoyenne-et/article/donnees-urbis-brussels-donnees on Monday July 8 Regards, Nicolas -- Nicolas Pettiaux, dr. sc ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Street with 2 names
Hi Marc, I already fixed it. Wasn't sure which name to use, but I saw in other examples that both names are combined to form the streetname. In this case Bronstraat - Hofstede. Gilbert On 5 June 2013 07:15, Marc Gemis marc.ge...@gmail.com wrote: With this overpass query http://overpass-turbo.eu/s/ip you can see all streets with name:left tag. I noticed there is one near Mol (Bronstraat, Hofstede) without a name tag, only name:left and name:right. Searching for those streets in Nominatim returns no answer (for that street). So my advice is to add a name tag as well. (Yes, I know do not tag for the renderer, but using an undocumented tag, which is not recognized by Nominatim is pretty useless (even when it's used 23.000 time -- see taginfo)) m On Tue, Jun 4, 2013 at 6:27 PM, Sander Deryckere sander...@gmail.comwrote: Both names are equal, so al_name isn't used indeed. Here's some other example: http://www.openstreetmap.org/browse/way/94237553 (inside the same town this time). But without associatedStreet relations. 2013/6/4 Ben Laenen benlae...@gmail.com There's actually name:left and name:right to tell which side is which. alt_name isn't used for this. Ben On Tuesday 04 June 2013 16:04:07 eMerzh wrote: What about using alt_name or smth? On Tue, Jun 4, 2013 at 3:57 PM, Marc Gemis marc.ge...@gmail.com wrote: The streetname can be street A - street B Osmose complains when you have street A;street B You can create 2 associated street relations, one for each street + city + postcode + houses on that side or if you do not create associated street relations, the name of the street + city + postcode on the houses on that side. Examples with associated Street relations http://www.openstreetmap.org/?lat=51.116914lon=4.395304zoom=18layers=M Pierstraat - Reetsesteenweg (Reet Aartselaar) http://www.openstreetmap.org/?lat=51.16592lon=4.42274zoom=17layers=M Jachtlaan (Antwerpen Edegem) same name in this case, but different cities postcodes m On Tue, Jun 4, 2013 at 1:24 PM, Teddy e...@swing.be wrote: Hello, What to do if a street have 2 names ? One side is in a town and the other side in another town ? Thanks. ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Street with 2 names
PS: when I add such a street to their associated street relations (obviously 2 separate relations), the JOSM validator complains. Shouldn't that be fixed ? Gilbert On 5 June 2013 19:55, Gilbert Hersschens gherssch...@gmail.com wrote: Hi Marc, I already fixed it. Wasn't sure which name to use, but I saw in other examples that both names are combined to form the streetname. In this case Bronstraat - Hofstede. Gilbert On 5 June 2013 07:15, Marc Gemis marc.ge...@gmail.com wrote: With this overpass query http://overpass-turbo.eu/s/ip you can see all streets with name:left tag. I noticed there is one near Mol (Bronstraat, Hofstede) without a name tag, only name:left and name:right. Searching for those streets in Nominatim returns no answer (for that street). So my advice is to add a name tag as well. (Yes, I know do not tag for the renderer, but using an undocumented tag, which is not recognized by Nominatim is pretty useless (even when it's used 23.000 time -- see taginfo)) m On Tue, Jun 4, 2013 at 6:27 PM, Sander Deryckere sander...@gmail.comwrote: Both names are equal, so al_name isn't used indeed. Here's some other example: http://www.openstreetmap.org/browse/way/94237553 (inside the same town this time). But without associatedStreet relations. 2013/6/4 Ben Laenen benlae...@gmail.com There's actually name:left and name:right to tell which side is which. alt_name isn't used for this. Ben On Tuesday 04 June 2013 16:04:07 eMerzh wrote: What about using alt_name or smth? On Tue, Jun 4, 2013 at 3:57 PM, Marc Gemis marc.ge...@gmail.com wrote: The streetname can be street A - street B Osmose complains when you have street A;street B You can create 2 associated street relations, one for each street + city + postcode + houses on that side or if you do not create associated street relations, the name of the street + city + postcode on the houses on that side. Examples with associated Street relations http://www.openstreetmap.org/?lat=51.116914lon=4.395304zoom=18layers=M Pierstraat - Reetsesteenweg (Reet Aartselaar) http://www.openstreetmap.org/?lat=51.16592lon=4.42274zoom=17layers=M Jachtlaan (Antwerpen Edegem) same name in this case, but different cities postcodes m On Tue, Jun 4, 2013 at 1:24 PM, Teddy e...@swing.be wrote: Hello, What to do if a street have 2 names ? One side is in a town and the other side in another town ? Thanks. ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] UrbIS - streetnumbers
Hi Anton, It seems that you understood the associated Street relation. You can now add additional information to the relation such as addr:city, addr:postalcode. I usually also add addr:country=BE I never add buildings without an explicit housenumber, thus I would remove the building under the numbers 103-109 from the relation. I thought that either JOSM or OSMOSE complains about this. As for the south part of Place de la Patrie. In the relationstab of JOSM, you can click on the relation. (Select), then press the edit button at the bottom of that panel. A dialog with the assoc.street opens. You can now select any element in the main edit window. It will appear on the right side of the dialog. Press any of the four top buttons in the middle. The element will be placed in the list on the left. Close the dialog. The element is now part of the relation. I already did it for the south side Happy mapping. m ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Street with 2 names
Yes, I know that JOSM complains that the street is in two relations. Osmose as well. There I report it as false positive. Osmose also complains that there are many names in the relation. I also mark those as false positive. I have no other solution. m On Wed, Jun 5, 2013 at 8:00 PM, Gilbert Hersschens gherssch...@gmail.comwrote: PS: when I add such a street to their associated street relations (obviously 2 separate relations), the JOSM validator complains. Shouldn't that be fixed ? Gilbert On 5 June 2013 19:55, Gilbert Hersschens gherssch...@gmail.com wrote: Hi Marc, I already fixed it. Wasn't sure which name to use, but I saw in other examples that both names are combined to form the streetname. In this case Bronstraat - Hofstede. Gilbert On 5 June 2013 07:15, Marc Gemis marc.ge...@gmail.com wrote: With this overpass query http://overpass-turbo.eu/s/ip you can see all streets with name:left tag. I noticed there is one near Mol (Bronstraat, Hofstede) without a name tag, only name:left and name:right. Searching for those streets in Nominatim returns no answer (for that street). So my advice is to add a name tag as well. (Yes, I know do not tag for the renderer, but using an undocumented tag, which is not recognized by Nominatim is pretty useless (even when it's used 23.000 time -- see taginfo)) m On Tue, Jun 4, 2013 at 6:27 PM, Sander Deryckere sander...@gmail.comwrote: Both names are equal, so al_name isn't used indeed. Here's some other example: http://www.openstreetmap.org/browse/way/94237553 (inside the same town this time). But without associatedStreet relations. 2013/6/4 Ben Laenen benlae...@gmail.com There's actually name:left and name:right to tell which side is which. alt_name isn't used for this. Ben On Tuesday 04 June 2013 16:04:07 eMerzh wrote: What about using alt_name or smth? On Tue, Jun 4, 2013 at 3:57 PM, Marc Gemis marc.ge...@gmail.com wrote: The streetname can be street A - street B Osmose complains when you have street A;street B You can create 2 associated street relations, one for each street + city + postcode + houses on that side or if you do not create associated street relations, the name of the street + city + postcode on the houses on that side. Examples with associated Street relations http://www.openstreetmap.org/?lat=51.116914lon=4.395304zoom=18layers=M Pierstraat - Reetsesteenweg (Reet Aartselaar) http://www.openstreetmap.org/?lat=51.16592lon=4.42274zoom=17layers=M Jachtlaan (Antwerpen Edegem) same name in this case, but different cities postcodes m On Tue, Jun 4, 2013 at 1:24 PM, Teddy e...@swing.be wrote: Hello, What to do if a street have 2 names ? One side is in a town and the other side in another town ? Thanks. ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] UrbIS - streetnumbers
Hi Anton, If you want to see how I do it 'live', contact me on google chat or on Skype (Polyglot.Openstreetmap). I'm usually 'invisible' so simply send a message and I'll let you know if/when I'm on line. The trick is to make use of the associatedStreet relations which are present in the 1xxx.osm files. Right mouse button, select members Then Right mouse button, select relation (add). If you install the scripting plugin I have a script which does that and some more automatically. I'm working on a script which does the integration if buildings are already present in the data, but it needs more testing. Jo 2013/6/5 Anton Snoeys antonsno...@gmail.com Hi everybody, I'm new to this and found your work, thumbs up guys :-) I recently tried to use the 1030.osm to add information for Schaarbeek in JOSM. I'm struggling a bit with the AssociatedStreet relations. Yesterday I added Rue Henri Evenepoel (Changeset: 16425586), could anybody please check if I added the information the right way? I woudn't want to continue adding wrong or incomplete information. Today I tried to add Place de la Patrie (Changeset 16434542) but I couldn't add both sides of the square to the same relation (probably because the square is just two one way roads?). Sorry to bother you guys with it, Cheers, FantAntonio On Wed, Jun 5, 2013 at 11:44 AM, Nicolas Pettiaux nico...@pettiaux.bewrote: 2013/6/5 Pierre Parmentier pierrecparment...@gmail.com: Hi, We can observe that where 'UrbIS' shows sometimes multiple streetnumbers on a particular building way, 'CadGIS Viewer Grand Public' is quite better (and univocal). Thanks for giving the link to this CadGIS viewer that I did not know. You affirmation is strange to me. I thought that there was Urbis was the reference in Brussels and that is was used by the cadaster ! I have just checked on http://www.cirb.irisnet.be/fr/catalogue-de-services/urbis and I realize that there are different Urbis products. THe one that is referenced I suppose that UrbIS-Map is used on the link that Pierre gives, while UrbIS-PB is related to the cadaster data. There must be some good explanation why these sets of data are different, but I also wonder if it would not be interesting if they where only different views of the same datas. Has anyone more information about these ? This may be a question to ask to the person who will preent Urbis during the rmll http://schedule2013.rmll.info/programme/les-donnees-ouvertes/participation-citoyenne-et/article/donnees-urbis-brussels-donnees on Monday July 8 Regards, Nicolas -- Nicolas Pettiaux, dr. sc ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
[OSM-legal-talk] Using data from Ville de Montréal
Hello, The Ville de Montréal has some interesting data available under their own licence: http://donnees.ville.montreal.qc.ca/licence/licence-texte-complet/ However clause 4 of the licence (attribution) is more restrictive than the terms of the ODbL, and thus the data cannot be used in OSM. Since this licence can and will change in the future (the city want to make it evolve to be on pair with other big North American cities), we would need a more permanent and explicit authorization from the city to use its data within OSM. Surely this situation is not the first of its kind to happen regarding OSM. Are there examples of how this was handled with other data sources? What would be the general guidelines to suggest to the city for such a legal document to authorize contributions of its data to OSM? Should the city somehow allow explicitly the relicensing of its data under the ODbL for the OpenSteetMap project? Thanks, Guillaume Pratte___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Donation wiki page: Flattr and Bitcoin
On 04.06.2013 23:09, Tobias Knerr wrote: In the light of the ongoing funding drive, I'd like to suggest some improvements to the (protected) wiki page where we send users looking for alternative payment options: [...] A link to http://wiki.openstreetmap.org/wiki/Merchandise could also be helpful. Thomas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Are there any guidelines for wiki admins ?
Hey After the dispute last week and another private issue, I wonder if there are any wiki-admin guidelines as I'd like to have a look at. * How are new admins instructed ? * Are there any golden rules ? * Is it clear for all admins that: * voting in the wiki is not that important ? * to discuss major changes in advanc on tagging@osm ? Thanks and cheers colliar signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Mapnik v2.2.0 Released
I'm pleased to announce that Mapnik 2.2.0 is ready. Download at the source, as well as binaries for iOS, OS X, Windows, and Ubuntu at http://mapnik.org/download/ The is the first Mapnik release to support 64 bit feature ids enabling filtering on id and and rendering grids [1] of OSM data. This is also the first Mapnik release to provide an API for vector tiles, which is available in a standalone repo [2]. This release also includes many performance improvements and bug fixes. See the release summary [3] and changelog [4] for full details. Dane [1] https://github.com/mapnik/mapnik/wiki/MapnikRenderers#grid_renderer [2] https://github.com/mapbox/mapnik-vector-tile. [3] https://github.com/mapnik/mapnik/wiki/MapnikReleases#220 [4] https://github.com/mapnik/mapnik/wiki/Release2.2.0 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
Am 05.06.2013 02:46, schrieb Tobias Conradi: 2013/6/5 Stefan Keller sfkel...@gmail.com: Man erfasst was man in der Realität draussen sieht. Buslinien sieht man nicht, ausser auf Netzplänen. Ich hab Buslinien durchaus schon - und zwar häufiger - eingetragen, indem ich mich zunächst reingesetzt habe und dabei das GPS hab loggen lassen. Damit sehe ich zwar nicht die Buslinie, aber kann sie sehr wohl nachvollziehen. Trotzdem gibt es Linien in OSM. Manche Relationen: http://www.wikidata.org/wiki/Q99691 (U1 Berlin) linkt zu : http://www.openstreetmap.org/?relation=58767 sogar ohne Kartendarstellung. Mehr Infos dann unter http://www.openstreetmap.org/browse/relation/58767 Die Darstellung gibt es sehr wohl, jedoch in Form einzelner Darstellungen der einzelnen Routen-Varianten und -Richtungen, z.B. http://www.openstreetmap.org/browse/relation/2669205 Und dort gibt es eine Farbangabe. Wenn man da keine will, dann könnte man das vielleicht technisch unterbinden, bzw. erstmal irgendwo definieren. Warum sollte ausgerechnet dieser Fall (Farben von ÖPNV-Linien) dazu führen, dass technische Hilfsmittel herangezogen werden, um ein bestimmtes Tagging zu behindern? Eine Farbe, die nirgendwo genutzt wird, stört auch niemanden. Eine Farbe, die nirgendwo genutzt wird, wird auch seltener eingetragen werden. Wird die Farbe irgendwo genutzt durch irgendeine Karte, dann ist das berechtigt und erst recht kein Grund, das zu unterbinden. Wenn man keine will, dann nutzt/erstellt man (sich? anderen? allen?) einen Kartenstil, der die Farbe nicht nutzt, und fertig. Wenn man eine will, kann man um die Bandbreite der Werte zu reduzieren, definieren welche Werte eingetragen werden sollen. Das war die Idee von CMYK und RGB Farben - Standardisierung in OSM. Hier kommen wir zum Kern des Threads: Es ist eben abzuwägen: - Ein Farbschema festlegen (z.B. RGB) führt dazu, dass Umwandlungen aus/in einige andere Farbschemata ungenau werden, es kommt also zu mehr oder weniger falschen Werten (was IMHO die meisten Mapper und die meisten OSM-Anwendungsfälle kaum stören dürfte, weil die Genauigkeit der Farben nicht sooo hoch sein muss). - Mehrere/viele/alle Farbschemata zu erlauben verlangt jeder auswertenden Instanz (Renderer...) ab, diese auch alle zu kennen und zumeist, die ungenaue Umwandlung dann vorzunehmen. Es finden sich also die Dimensionen: - Aufwand für das Eintragen durch Mapper - Aufwand für das Verifizieren und korrigiern durch Mapper - Aufwand und Möglichkeit, die Daten auszuwerten im Rendering - Bedarf an Genauigkeit der Farben (z.B. reichen die ~64 benannten Farben aus Windows aus? oder sowas) Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
On 05/giu/2013, at 02:56, Tobias Conradi mail.2...@tobiasconradi.com wrote: Mir ist nicht klar, für was genau diese Farben-Normierung dient Bandbreite der möglichen Werte reduzieren, möglichst eine eindeutige Abbildung. Dadurch Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen. bis auf Bandbreite der Möglichkeiten reduzieren sind das allerdings allesamt Argumente gegen eine Normierung auf RGB. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
Tobias Conradi mail.2...@tobiasconradi.com wrote: Bandbreite der möglichen Werte reduzieren, möglichst eine eindeutige Abbildung. Dadurch Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen. Dir ist aber schon klar, dass es Eindeutigkeit in croudsourcing Projekten wie OSM sowieso nie geben wird? Ich finde das ja ehrlich gesagt alles massiv überspezifiziert. Einfach die Klartextnamen aus rgb.txt verwenden und gut iss. Gruss Sven -- If you can spend five minutes on the Internet and do not run Linux, you're a genius. (Dirk Hohndel) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Widersprüche zwischen Wiki-Definition und Mapnik-Rendering
Am Mittwoch, den 05.06.2013, 01:47 +0200 schrieb Martin Koppenhoefer: Am 5. Juni 2013 01:36 schrieb Stephan Wolff s.wo...@web.de: Mangelt es dem Mapnik-Team nur an Zeit oder besteht Uneinigkeit in der korrekten Definition der Tags? Würde es helfen, eine verbesserte osm2pgsql-Konfiguration zu erstellen? Wem könnte man diese schicken? Das Problem ist, wie osm2pgsql arbeitet, man kann nur keys als Fläche zuordnen, aber nicht k/v-Paare, d.h. im Zweifel wird man eher ein Liniendefault setzen und nur mit area=yes auf Fläche gehen, weil sonst so was wie bei leisure=track passiert (leisure wird immer als area angesehen). Als Lösung kann man auf einen Area-Datentyp hoffen, oder darauf, dass man auch k/v-Kombinationen in osm2pgsql styles definieren kann. Oder z.B. einen anderen Importer verwenden, Imposm kann das vielleicht? osm2postgresql oder besser gleich osmosis, viel flexibler osm2pgsql filtert im Vorwege zu viel weg. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Am 05.06.2013 02:46, schrieb Tobias Conradi: 2013/6/5 Stefan Keller sfkel...@gmail.com: Man erfasst was man in der Realität draussen sieht. Buslinien sieht man nicht, ausser auf Netzplänen. Ich hab Buslinien durchaus schon - und zwar häufiger - eingetragen, indem ich mich zunächst reingesetzt habe und dabei das GPS hab loggen lassen. Damit sehe ich zwar nicht die Buslinie, aber kann sie sehr wohl nachvollziehen. Trotzdem gibt es Linien in OSM. Manche Relationen: http://www.wikidata.org/wiki/Q99691 (U1 Berlin) linkt zu : http://www.openstreetmap.org/?relation=58767 sogar ohne Kartendarstellung. Mehr Infos dann unter http://www.openstreetmap.org/browse/relation/58767 Die Darstellung gibt es sehr wohl, Jetzt bin ich ja gespannt. jedoch in Form einzelner Darstellungen der einzelnen Routen-Varianten und -Richtungen, z.B. http://www.openstreetmap.org/browse/relation/2669205 Also doch nicht. Und dort gibt es eine Farbangabe. Wenn man da keine will, dann könnte man das vielleicht technisch unterbinden, bzw. erstmal irgendwo definieren. Warum sollte ausgerechnet dieser Fall (Farben von ÖPNV-Linien) dazu führen, dass technische Hilfsmittel herangezogen werden, um ein bestimmtes Tagging zu behindern? Weil ausgerechnet dieser Fall angeführt wurde. Eine Farbe, die nirgendwo genutzt wird, stört auch niemanden. Das ist wohl wahr, nur kenne ich keine solche. Und sobald Du eine benennst, ist sie genutzt. Eine Farbe, die nirgendwo genutzt wird, wird auch seltener eingetragen werden. So selten, dass man von gar nicht reden würde. Denn würde sie eingetragen werden, würde sie ja genutzt werden. Wird die Farbe irgendwo genutzt durch irgendeine Karte, dann ist das berechtigt und erst recht kein Grund, das zu unterbinden. Eine in der Vergangenheit erfolgte Handlung (irgendwo Nutzung) kann man auch gar nicht unterbinden. Wenn man keine will, dann nutzt/erstellt man (sich? anderen? allen?) einen Kartenstil, der die Farbe nicht nutzt, und fertig. Oder man löscht alle Farbtags in OSM .. und fertig. Wenn man eine will, kann man um die Bandbreite der Werte zu reduzieren, definieren welche Werte eingetragen werden sollen. Das war die Idee von CMYK und RGB Farben - Standardisierung in OSM. Hier kommen wir zum Kern des Threads: Es ist eben abzuwägen: - Ein Farbschema festlegen (z.B. RGB) Dies ist bereits festgelegt: http://wiki.openstreetmap.org/wiki/Key:colour The value should be: * an RGB color code (hex triplet) * a CSS color name führt dazu, dass Umwandlungen aus/in einige andere Farbschemata ungenau werden, es kommt also zu mehr oder weniger falschen Werten (was IMHO die meisten Mapper und die meisten OSM-Anwendungsfälle kaum stören dürfte, weil die Genauigkeit der Farben nicht sooo hoch sein muss). Und was stört in einem solchen Fall wo sie nicht sooo hoch sein muss, eine höhre Genauigkeit? Es finden sich also die Dimensionen: - Aufwand für das Eintragen durch Mapper - Aufwand für das Verifizieren und korrigiern durch Mapper - Aufwand und Möglichkeit, die Daten auszuwerten im Rendering - Bedarf an Genauigkeit der Farben (z.B. reichen die ~64 benannten Farben aus Windows aus? oder sowas) Neben Aufwand gibt es noch Ertrag/Nutzen. Und der ist bei höherer Bestimmtheit der schon vorhandenen RGB-triplets höher. Wenn für Verkehrslinien keine RGB-triplets als Wertangaben existieren sollen, sondern nur benannte CSS-RGB-Farben, dann kann man das im Wiki definieren und/oder technisch ausschließen. Dies ist zur Zeit nicht der Fall. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
2013/6/5 Martin Koppenhoefer dieterdre...@gmail.com: Mir ist nicht klar, für was genau diese Farben-Normierung dient Bandbreite der möglichen Werte reduzieren, möglichst eine eindeutige Abbildung. Dadurch Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen. bis auf Bandbreite der Möglichkeiten reduzieren sind das allerdings allesamt Argumente gegen eine Normierung auf RGB. Beweisführung? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
2013/6/5 Sven Geggus li...@fuchsschwanzdomain.de: Tobias Conradi mail.2...@tobiasconradi.com wrote: Bandbreite der möglichen Werte reduzieren, möglichst eine eindeutige Abbildung. Dadurch Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen. Dir ist aber schon klar, dass es Eindeutigkeit in croudsourcing Projekten wie OSM sowieso nie geben wird? Nein. Ich finde das ja ehrlich gesagt alles massiv überspezifiziert. Einfach die Klartextnamen aus rgb.txt verwenden und gut iss. Wo befindet sich diese Datei um den Wahrheitsgehalt der Aussage überprüfen zu können? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
Am Mittwoch, den 05.06.2013, 08:31 +0200 schrieb Peter Wendorff: Am 05.06.2013 02:46, schrieb Tobias Conradi: Und dort gibt es eine Farbangabe. Wenn man da keine will, dann könnte man das vielleicht technisch unterbinden, bzw. erstmal irgendwo definieren. Warum sollte ausgerechnet dieser Fall (Farben von ÖPNV-Linien) dazu führen, dass technische Hilfsmittel herangezogen werden, um ein bestimmtes Tagging zu behindern? Eine Farbe, die nirgendwo genutzt wird, stört auch niemanden. Eine Farbe, die nirgendwo genutzt wird, wird auch seltener eingetragen werden. Wird die Farbe irgendwo genutzt durch irgendeine Karte, dann ist das berechtigt und erst recht kein Grund, das zu unterbinden. +1 Wenn man keine will, dann nutzt/erstellt man (sich? anderen? allen?) einen Kartenstil, der die Farbe nicht nutzt, und fertig. Wenn man eine will, kann man um die Bandbreite der Werte zu reduzieren, definieren welche Werte eingetragen werden sollen. Das war die Idee von CMYK und RGB Farben - Standardisierung in OSM. Hier kommen wir zum Kern des Threads: Es ist eben abzuwägen: - Ein Farbschema festlegen (z.B. RGB) führt dazu, dass Umwandlungen aus/in einige andere Farbschemata ungenau werden, es kommt also zu mehr oder weniger falschen Werten +1 (was IMHO die meisten Mapper und die meisten OSM-Anwendungsfälle kaum stören dürfte, weil die Genauigkeit der Farben nicht sooo hoch sein muss). Wie schon mehrfach geschrieben, es kommt auf den Anwendungsfall an. Für Web +1, für Print -1 / 0 - Mehrere/viele/alle Farbschemata zu erlauben verlangt jeder auswertenden Instanz (Renderer...) ab, diese auch alle zu kennen und zumeist, die ungenaue Umwandlung dann vorzunehmen. -1 warum? Es reicht, wenn die Instanz das auswertet, was sie braucht / kennt. Wenn RGB reicht, wertet die Instanz RGB aus. Wenn nur RAL eingetragen ist, erscheint die Farbe eben als grau. colour:rgb=dark_blue colour:ral=night_blue_26 so what? Die Instanz _kann_ auswerten, muss aber nicht. Es finden sich also die Dimensionen: - Aufwand für das Eintragen durch Mapper Siehe mein Vorschlag mit im Wiki zu definierenden Farbnamen - Aufwand für das Verifizieren und korrigiern durch Mapper Ist dann gering - Aufwand und Möglichkeit, die Daten auszuwerten im Rendering Sache der Instanz, bei verschiedenen Schemata relativ einfach. - Bedarf an Genauigkeit der Farben (z.B. reichen die ~64 benannten Farben aus Windows aus? oder sowas) Die können gerne im Wiki eingetragen werden. Aber bitte nicht davon ausgehen, dass die jeder kennt. Windows ist nur eins der eingesetzten OS. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
Am Mittwoch, den 05.06.2013, 13:09 +0200 schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Wenn man keine will, dann nutzt/erstellt man (sich? anderen? allen?) einen Kartenstil, der die Farbe nicht nutzt, und fertig. Oder man löscht alle Farbtags in OSM .. und fertig. ??? WIE BITTE ??? An dieser Stelle habe ich mich wohl verlesen?! Wenn man eine will, kann man um die Bandbreite der Werte zu reduzieren, definieren welche Werte eingetragen werden sollen. Das war die Idee von CMYK und RGB Farben - Standardisierung in OSM. Hier kommen wir zum Kern des Threads: Es ist eben abzuwägen: - Ein Farbschema festlegen (z.B. RGB) Dies ist bereits festgelegt: http://wiki.openstreetmap.org/wiki/Key:colour The value should be: * an RGB color code (hex triplet) * a CSS color name s/festgelegt/vorgeschlagen/g Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
2013/6/5 Wolfgang Hinsch osm-lis...@ivkasogis.de: Am Mittwoch, den 05.06.2013, 13:09 +0200 schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Wenn man keine will, dann nutzt/erstellt man (sich? anderen? allen?) einen Kartenstil, der die Farbe nicht nutzt, und fertig. Oder man löscht alle Farbtags in OSM .. und fertig. ??? WIE BITTE ??? An dieser Stelle habe ich mich wohl verlesen?! Ich weiß ja nicht was Du gelesen hast :-) Wenn das einzige Ziel ist, keine Farben zu haben, dann ist Löschen der Farben wohl zielführend, nicht? Hier kommen wir zum Kern des Threads: Es ist eben abzuwägen: - Ein Farbschema festlegen (z.B. RGB) Dies ist bereits festgelegt: http://wiki.openstreetmap.org/wiki/Key:colour ... s/festgelegt/vorgeschlagen/g Annahme: Vor der Festlegung von RGB wurde RGB vorgeschlagen. Schlußfolgerung: Auch das Vorschlagen von RGB ist schon geschehen. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
Hallo Tobias. Am 05.06.2013 13:10, schrieb Tobias Conradi: 2013/6/5 Martin Koppenhoefer dieterdre...@gmail.com: Mir ist nicht klar, für was genau diese Farben-Normierung dient Bandbreite der möglichen Werte reduzieren, möglichst eine eindeutige Abbildung. Dadurch Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen. bis auf Bandbreite der Möglichkeiten reduzieren sind das allerdings allesamt Argumente gegen eine Normierung auf RGB. Beweisführung? Dieses kurz-mal-mit-einem-wort-den-Ball-zurückspielen nervt wirklich irgendwann, sorry. Was willst du denn jetzt bewiesen haben? -Bandbreite möglicher Werte: da hat Martin dir recht gegeben -eindeutige Abbildung: Lies dich mal durch die verwandten Diskussionen der letzten Tage und stelle selbst fest, dass offensichtlich z.B. zwischen RAL und RGB keine eindeutige Abbildung existiert, bzw. dass da unterschiedliche Konvertierungstabellen/(Algorithmen?) existieren. Wenn aber die Abbildung nicht eindeutig und klar definiert ist (weil sie widersprüchlich mehrfach definiert ist), dann ist eben eine eindeutige Abbildung nach Normierung auf RGB nicht möglich (es sei denn, man einigt sich dabei auf eine Konvertierung - aber welche?) - Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen: Kann man IMHO als Argument sowohl für als auch gegen Normierung auf RGB auslegen. Pro nur-RGB daran: ein Vergleich zweier Werte führt zumindest immer zum gleichen Ergebnis, weil keine Umwandlung zum Vergleichen notwendig ist. Contra nur-RGB: Da ja (s.o.) die eindeutige Zuordnung schon beim Eintragen nicht als gegeben angenommen werden kann, sind zwei RGB-Werte, die zwei Mapper aus identischem RAL-Code umgewandelt haben, nicht zwingend gleich, so dass ein Vergleichen schwierig ist. Martins Aussagen waren erstmal eine Meinung - seine Einschätzung, wofür diese Argumente taugen. Eine Einschätzung beweisen zu müssen ist erstmal... - komisch. Mit Argumenten untermauern: okay, ja - hab ich hiermit glaub ich getan. Beweisen? Wieso? In einer Argumentation muss ich erstmal nicht beweisen, solange ich mir einig bin, und da wir hier nicht Mathematik, sondern Konversation betreiben, muss ich für Meinungen auch keinen wasserdichten, logisch 100% schlüssigen Beweis abliefern, sondern auf Nachfrage begründen, oder Gegenargumente entkräftigen/widerlegen. Ich hab jetzt hier 'ne halbe Bildschirmseite Begründungen geschrieben, die erstmal kaum jemanden interessieren dürften - außer hoffentlich wenigstens dir, weil du gefragt hast. Wenn das bei jeder Meinungsäußerung als Rattenschwanz dranhängt, liest hier wirklich niemand mehr alle Mails. Analogie: Der Satz des Pythagoras gilt. - du würdest schreien: Beweisführung? - aber eigentlich sind sich fast alle einig, dass es stimmt. Einen Beweis mitzuliefern ist also nur notwendig, wenn jemand zurückfragt, und das aber bitte konkret, und nicht mit einem Wort totgeschlagen. Warum soll sich jemand die Mühe machen, dir einen Beweis zu liefern, wenn Du dich auf - mehrfach identisch - ein einziges Wort begrenzt? Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
Am 05.06.2013 13:45, schrieb Tobias Conradi: 2013/6/5 Wolfgang Hinsch osm-lis...@ivkasogis.de: Am Mittwoch, den 05.06.2013, 13:09 +0200 schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Wenn man keine will, dann nutzt/erstellt man (sich? anderen? allen?) einen Kartenstil, der die Farbe nicht nutzt, und fertig. Oder man löscht alle Farbtags in OSM .. und fertig. ??? WIE BITTE ??? An dieser Stelle habe ich mich wohl verlesen?! Ich weiß ja nicht was Du gelesen hast :-) Wenn das einzige Ziel ist, keine Farben zu haben, dann ist Löschen der Farben wohl zielführend, nicht? Niemand hat argumentiert, es sollte keine Farben in OSM geben. Mit welchem Recht sollte irgendein Nutzer (z.B. Kartenstil-Entwickler) entscheiden, dass niemand die Farben will? Wenn ich auf meiner Karte keine Farben anzeigen will, nutze ich sie nicht. Wenn Hans Huckebein eine ÖPNV-Karte machen und darin die colour-Tags zur Einfärbung der Linien nutzen will, kann er das tun. Mein Ziel ist hier, ÖPNV-Linien ohne Farben darzustellen, und möglicherweise meine Datenbank zu schonen (indem ich die Farb-Attribute nicht importiere), aber dafür muss ich niemanden anderen an der Verwendung des Attributs hindern durch Löschung, wie du sie vorschlägst. Hier kommen wir zum Kern des Threads: Es ist eben abzuwägen: - Ein Farbschema festlegen (z.B. RGB) Dies ist bereits festgelegt: http://wiki.openstreetmap.org/wiki/Key:colour ... s/festgelegt/vorgeschlagen/g Annahme: Vor der Festlegung von RGB wurde RGB vorgeschlagen. Schlußfolgerung: Auch das Vorschlagen von RGB ist schon geschehen. Ich sehe hier nur eine Wiki-Seite. Kein Proposal, keine Abstimmung, kein gar nichts. Eine Festlegung in OSM sieht anders aus - wenn es sie denn überhaupt gibt. Natürlich muss nicht alles durch einen formalen Proposal-Tag gehen, aber das als festgelegt zu bezeichnen, wenn es ganz offensichtlichen Dissenz gibt (wie du hoffentlich mittlerweile gemerkt hast), und es keine Abstimmung gegeben hat (nichtmal eine kleine, wie es sie häufig gibt), kann nun von einer Festlegung wirklich nicht die Rede sein. Ansonsten könnte ich mal - spezifischer als du bisher Beweisführung! schreien, indem ich frage: Wo ist das denn FESTGELEGT? Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
On 05/giu/2013, at 13:10, Tobias Conradi mail.2...@tobiasconradi.com wrote: Bandbreite der möglichen Werte reduzieren, möglichst eine eindeutige Abbildung. Dadurch Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen. bis auf Bandbreite der Möglichkeiten reduzieren sind das allerdings allesamt Argumente gegen eine Normierung auf RGB. Beweisführung? s.o. im Thread m ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Hallo Tobias. Am 05.06.2013 13:10, schrieb Tobias Conradi: 2013/6/5 Martin Koppenhoefer dieterdre...@gmail.com: Mir ist nicht klar, für was genau diese Farben-Normierung dient Bandbreite der möglichen Werte reduzieren, möglichst eine eindeutige Abbildung. Dadurch Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen. bis auf Bandbreite der Möglichkeiten reduzieren sind das allerdings allesamt Argumente gegen eine Normierung auf RGB. Beweisführung? Dieses kurz-mal-mit-einem-wort-den-Ball-zurückspielen nervt wirklich irgendwann, sorry. Dieses lang-mal-irgendwas-behaupten nicht? Was willst du denn jetzt bewiesen haben? Warum Argumente gegen Normierung sprechen. Denn sie waren ja alle als für gedacht. -Bandbreite möglicher Werte: da hat Martin dir recht gegeben -eindeutige Abbildung: Lies dich mal durch die verwandten Diskussionen der letzten Tage und stelle selbst fest, dass offensichtlich z.B. zwischen RAL und RGB keine eindeutige Abbildung existiert, Lies du mal und stelle fest es gibt. Es gibt mehrere. bzw. dass da unterschiedliche Konvertierungstabellen/(Algorithmen?) existieren. Wählt man eine, dann hat man eine eindeutige Abbildung. Wenn aber die Abbildung nicht eindeutig und klar definiert ist (weil sie widersprüchlich mehrfach definiert ist), dann ist eben eine eindeutige Abbildung nach Normierung auf RGB nicht möglich (es sei denn, man einigt sich dabei auf eine Konvertierung - aber welche?) Ich habe einen Vorschlag für CMYK zu RGB gemacht und begründet. CMYK ist das einzige System von dem ich weiß dass ein Verkehrsverbund es nutzt. Von RAL ist mir das nicht bekannt. - Vorhersagbarkeit der Werte und Übereinstimmung mit Farbwerten in anderen Datenquellen: Kann man IMHO als Argument sowohl für als auch gegen Normierung auf RGB auslegen. Pro nur-RGB daran: ein Vergleich zweier Werte führt zumindest immer zum gleichen Ergebnis, weil keine Umwandlung zum Vergleichen notwendig ist. Contra nur-RGB: Da ja (s.o.) die eindeutige Zuordnung schon beim Eintragen nicht als gegeben angenommen werden kann, sind zwei RGB-Werte, die zwei Mapper aus identischem RAL-Code umgewandelt haben, nicht zwingend gleich, so dass ein Vergleichen schwierig ist. Ich hatte kein nur-RGB vorgeschlagen. Der Vorschlag lautete nur, wenn RGB, dann eine eindeutige Herleitung. Martins Aussagen waren erstmal eine Meinung - seine Einschätzung, wofür diese Argumente taugen. Ohne Beweisführung :-) Eine Einschätzung beweisen zu müssen ist erstmal... - komisch. Martin hat wahrscheinlich irgendetwas im (Hinter-)Kopf gehabt, als er seinen Text schrieb. Diese Hintergedanken wollte ich hervorlocken. Es können da ja Denkfehler drinstecken. Mit Argumenten untermauern: okay, ja - hab ich hiermit glaub ich getan. Und ich habe gleich einige Dinge dazu ergänzt. Beweisen? Wieso? Damit die Behauptungen mehr Sinn ergeben. In einer Argumentation muss ich erstmal nicht beweisen, Dass jemand etwas muss, ist m.E. schwer zu beweisen. solange ich mir einig bin, und da wir hier nicht Mathematik, sondern Konversation betreiben, muss ich für Meinungen auch keinen wasserdichten, logisch 100% schlüssigen Beweis abliefern, sondern auf Nachfrage begründen, oder Gegenargumente entkräftigen/widerlegen. Eine solche Nachfrage war mein Beweisführung? Ich hab jetzt hier 'ne halbe Bildschirmseite Begründungen geschrieben, die erstmal kaum jemanden interessieren dürften Mich ja :-) - außer hoffentlich wenigstens dir, weil du gefragt hast. :-) Analogie: Der Satz des Pythagoras gilt. - du würdest schreien: Beweisführung? Mmmh, schreien oder schreiben? - aber eigentlich sind sich fast alle einig, dass es stimmt. Einen Beweis mitzuliefern ist also nur notwendig, wenn jemand zurückfragt, und das aber bitte konkret, und nicht mit einem Wort totgeschlagen. Warum soll sich jemand die Mühe machen, dir einen Beweis zu liefern, wenn Du dich auf - mehrfach identisch - ein einziges Wort begrenzt? Weil er seine in den Raum gestellten Behauptungen untermauern will, da sie nicht den Rang eines Satzes des Pythagoras haben, auf dessen Herleitung man auch einfach mit einem Link zu Wikipedia https://de.wikipedia.org/wiki/Satz_des_Pythagoras verweisen kann. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
On 05/giu/2013, at 14:04, Peter Wendorff wendo...@uni-paderborn.de wrote: Kann man IMHO als Argument sowohl für als auch gegen Normierung auf RGB auslegen. Pro nur-RGB daran: ein Vergleich zweier Werte führt zumindest immer zum gleichen Ergebnis, weil keine Umwandlung zum Vergleichen notwendig ist. Contra nur-RGB: Da ja (s.o.) die eindeutige Zuordnung schon beim Eintragen nicht als gegeben angenommen werden kann, sind zwei RGB-Werte, die zwei Mapper aus identischem RAL-Code umgewandelt haben, nicht zwingend gleich, so dass ein Vergleichen schwierig ist. +1 und -Konversion ist nicht umkehrbar -nicht alle Farben sind in RGB darstellbar -offizielle Festlegungen sind z.T. nicht in RGB (wo bleibt da dann die Vergleichbarkeit?) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
2013/6/5 Martin Koppenhoefer dieterdre...@gmail.com: -Konversion ist nicht umkehrbar Ich nannte Eindeutigkeit und nicht Eineindeutigkeit. -nicht alle Farben sind in RGB darstellbar Das spricht nicht gegen eine eindeutige Abbildung im RGB-Raum -offizielle Festlegungen sind z.T. nicht in RGB (wo bleibt da dann die Vergleichbarkeit?) Vergleichbarkeit wurde von mir nicht angeführt. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
On 05/giu/2013, at 14:52, Tobias Conradi mail.2...@tobiasconradi.com wrote: Weil er seine in den Raum gestellten Behauptungen untermauern will, da sie nicht den Rang eines Satzes des Pythagoras haben, auf dessen Herleitung man auch einfach mit einem Link zu Wikipedia https://de.wikipedia.org/wiki/Satz_des_Pythagoras verweisen kann. ein bisschen WP. lesen könnte Dir hier vielleicht auch helfen http://de.m.wikipedia.org/wiki/RGB-Farbraum z.B.: Für digitale Bilddaten eignet sich der RGB-Farbraum lediglich zur Darstellung am Bildschirm und den verwandten Gerätetypen. Bilddaten für den Druck (Offsetdruck, Siebdruck, Digitaldruck) sind in einem subtraktiven Farbmodell zu reproduzieren (CMY, CMYK) oder: Im RGB-Farbraum sind nicht alle Farbvalenzen enthalten. Insbesondere die gesättigten Spektralfarben erfordern negative Wiedergabeanteile (äußere Farbmischung), das wäre fehlendes Licht. oder: Ein RGB-Farbraum ist ein auf wenige, definierte Parameter begrenzter Ausschnitt der Wirklichkeit. Die Wahrnehmung eines „bunten“ Lichtes, einer „Oberfläche“, umfasst weitere Effekte. So könnte die Definition einer Farbe durch drei Zahlen die falsche Erwartung wecken, eine Farbe wäre in ihrer Wahrnehmung absolut bestimmt. Tatsächlich ist die Farbwirkung einer numerisch bestimmten RGB-Farbe dagegen vom konkret vorhandenen technischen System abhängig, das diese Farbe wiedergibt oder aufnimmt, und auch von den internen und externen Umgebungsbedingungen. Ein Beispiel: Die Farbwerte 100 % Rot, 50 % Grün und 0 % Blau (rgb = 255,127,0) ergeben ein Orange, die Nuance des Orange kann auch bei guter Voreinstellung auf verschiedenen Wiedergabegeräten sehr unterschiedlich aussehen. und auch: Es ist also für eine gute Farbdarstellung wichtig zu wissen, welche RGB-Norm eingesetzt wurde. alle vg. Zitate von der o.g. Wikip.seite, interessant ist aber ggf auch http://de.m.wikipedia.org/wiki/Farbreproduktion und die Seite zu CMYK und die zu RAL oder pantone Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
On 05/giu/2013, at 14:56, Tobias Conradi mail.2...@tobiasconradi.com wrote: -nicht alle Farben sind in RGB darstellbar Das spricht nicht gegen eine eindeutige Abbildung im RGB-Raum wenn einem eindeutig unzureichend ausreicht... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Am 05.06.2013 13:45, schrieb Tobias Conradi: 2013/6/5 Wolfgang Hinsch osm-lis...@ivkasogis.de: Am Mittwoch, den 05.06.2013, 13:09 +0200 schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Wenn man keine will, dann nutzt/erstellt man (sich? anderen? allen?) einen Kartenstil, der die Farbe nicht nutzt, und fertig. Oder man löscht alle Farbtags in OSM .. und fertig. .. Wenn das einzige Ziel ist, keine Farben zu haben, dann ist Löschen der Farben wohl zielführend, nicht? Niemand hat argumentiert, es sollte keine Farben in OSM geben. http://lists.openstreetmap.org/pipermail/talk-de/2013-June/102605.html primär Vektordatenbank, Farben kaum eine Rolle, erst beim Rendern Darufhin habe ich gesagt [Für die U1 in Berlin] gibt es eine Farbangabe. Wenn man da keine will, dann könnte man das vielleicht technisch unterbinden, bzw. erstmal irgendwo definieren. Dann wurde gesagt, wenn man keine will, dann macht man das im Kartenstil und fertig. Das habe ich wieder zurückgedreht auf, dann kann man die auch in OSM löschen. Es ging ja nicht darum die nur beim Rendern zu unterdrücken, sondern um die konkreten Tags in der DB. Mit welchem Recht sollte irgendein Nutzer (z.B. Kartenstil-Entwickler) entscheiden, dass niemand die Farben will? Das kann niemand entscheiden. Aber es kann jemand entscheiden, dass sie nicht mehr in OSM gespeichert wird. Rechte dazu haben sicher einige Personen, so wie manche Personen ja auch im Wiki oder in den Emailarchiven Löschrechte haben, haben sicher auch manche Personen Softwareschreibrechte. Wenn Hans Huckebein eine ÖPNV-Karte machen und darin die colour-Tags zur Einfärbung der Linien nutzen will, kann er das tun. Klar. Mein Ziel ist hier, ÖPNV-Linien ohne Farben darzustellen, Gut. Dann gehörst Du nicht zu denen die von meinem Vorschlag zur Standardisierung direkt profitieren. Hier kommen wir zum Kern des Threads: Es ist eben abzuwägen: - Ein Farbschema festlegen (z.B. RGB) Dies ist bereits festgelegt: http://wiki.openstreetmap.org/wiki/Key:colour Annahme: Vor der Festlegung von RGB wurde RGB vorgeschlagen. Schlußfolgerung: Auch das Vorschlagen von RGB ist schon geschehen. Ich sehe hier nur eine Wiki-Seite. Kein Proposal, keine Abstimmung, kein gar nichts. Eine Festlegung in OSM sieht anders aus Wie? Natürlich muss nicht alles durch einen formalen Proposal-Tag gehen, aber das als festgelegt zu bezeichnen, wenn es ganz offensichtlichen Dissenz gibt (wie du hoffentlich mittlerweile gemerkt hast), Ich sehe weder auf der Wikiseite einen Dissenz noch in der realen Verwendung wie unter http://taginfo.openstreetmap.org/keys/colour#values einsehbar. und es keine Abstimmung gegeben hat (nichtmal eine kleine, wie es sie häufig gibt), Gibt es eine offizielle List über alle Abstimmungen anhand derer sich Deine Aussage überprüfen lässt? kann nun von einer Festlegung wirklich nicht die Rede sein. Eine Festlegung kann auch ohne Abstimmung erfolgen. Es genügt eine Person. Ansonsten könnte ich mal - spezifischer als du bisher Beweisführung! schreien, schreien? indem ich frage: Wo ist das denn FESTGELEGT? http://wiki.openstreetmap.org/wiki/Key:colour The value should be: * an RGB color code (hex triplet) ... * a CSS color name -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
2013/6/5 Martin Koppenhoefer dieterdre...@gmail.com: On 05/giu/2013, at 14:52, Tobias Conradi mail.2...@tobiasconradi.com wrote: Weil er seine in den Raum gestellten Behauptungen untermauern will, da sie nicht den Rang eines Satzes des Pythagoras haben, auf dessen Herleitung man auch einfach mit einem Link zu Wikipedia https://de.wikipedia.org/wiki/Satz_des_Pythagoras verweisen kann. ein bisschen WP. lesen könnte Dir hier vielleicht auch helfen http://de.m.wikipedia.org/wiki/RGB-Farbraum z.B.: Für digitale Bilddaten eignet sich der RGB-Farbraum lediglich zur Darstellung am Bildschirm und den verwandten Gerätetypen. Bilddaten für den Druck (Offsetdruck, Siebdruck, Digitaldruck) sind in einem subtraktiven Farbmodell zu reproduzieren (CMY, CMYK) oder: Im RGB-Farbraum sind nicht alle Farbvalenzen enthalten. Insbesondere die gesättigten Spektralfarben erfordern negative Wiedergabeanteile (äußere Farbmischung), das wäre fehlendes Licht. oder: Ein RGB-Farbraum ist ein auf wenige, definierte Parameter begrenzter Ausschnitt der Wirklichkeit. Die Wahrnehmung eines „bunten“ Lichtes, einer „Oberfläche“, umfasst weitere Effekte. So könnte die Definition einer Farbe durch drei Zahlen die falsche Erwartung wecken, eine Farbe wäre in ihrer Wahrnehmung absolut bestimmt. Tatsächlich ist die Farbwirkung einer numerisch bestimmten RGB-Farbe dagegen vom konkret vorhandenen technischen System abhängig, das diese Farbe wiedergibt oder aufnimmt, und auch von den internen und externen Umgebungsbedingungen. Ein Beispiel: Die Farbwerte 100 % Rot, 50 % Grün und 0 % Blau (rgb = 255,127,0) ergeben ein Orange, die Nuance des Orange kann auch bei guter Voreinstellung auf verschiedenen Wiedergabegeräten sehr unterschiedlich aussehen. und auch: Es ist also für eine gute Farbdarstellung wichtig zu wissen, welche RGB-Norm eingesetzt wurde. alle vg. Zitate von der o.g. Wikip.seite, interessant ist aber ggf auch http://de.m.wikipedia.org/wiki/Farbreproduktion und die Seite zu CMYK und die zu RAL oder pantone Habe in Deinen Zitaten nichts neues gesehen und sehe auch nicht, dass sie irgendeine meiner in den letzten zwei Wochen gemachten Behauptungen widerlegen. Sollte ein Zitat einer von mir aufgestellten Behauptung widersprechen, bitte ich um ein Zitat der Behauptung. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
On 05/giu/2013, at 15:16, Tobias Conradi mail.2...@tobiasconradi.com wrote: Aber es kann jemand entscheiden, dass sie nicht mehr in OSM gespeichert wird. so, wer denn? m ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
On 05/giu/2013, at 15:16, Tobias Conradi mail.2...@tobiasconradi.com wrote: Eine Festlegung in OSM sieht anders aus Wie? in erster Linie ist es immer ein weitgehender Konsens oder zumindest akzeptierter Kompromiss Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
2013/6/5 Martin Koppenhoefer dieterdre...@gmail.com: -nicht alle Farben sind in RGB darstellbar Das spricht nicht gegen eine eindeutige Abbildung im RGB-Raum wenn einem eindeutig unzureichend ausreicht... http://lists.openstreetmap.org/pipermail/talk-de/2013-May/102567.html 5) erlaubt nur RGB. Wenn jemand mehr als RGB möchte, dann ist dies ausserhalb dessen, was mein Standardisierungsvorschlag erreichen möchte. Eindeutige Abbildung im RGB-Raum war als Gegensatz zu nicht eindeutiger Abbildung im RGB-Raum gemeint. Und RGB meint hier letztlich immer sRGB. https://de.wikipedia.org/wiki/SRGB http://www.w3.org/Graphics/Color/sRGB.html -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
2013/6/5 Martin Koppenhoefer dieterdre...@gmail.com: Eine Festlegung in OSM sieht anders aus Wie? in erster Linie ist es immer ein weitgehender Konsens Ein Konsens ist nach meinem Verständnis der deutschen Sprache keine Festlegung. oder zumindest akzeptierter Kompromiss Ein akzeptierter Kompromiss ist nach meinem Verständnis der deutschen Sprache keine Festlegung. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
Am 05.06.2013 15:16, schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: und es keine Abstimmung gegeben hat (nichtmal eine kleine, wie es sie häufig gibt), Gibt es eine offizielle List über alle Abstimmungen anhand derer sich Deine Aussage überprüfen lässt? Andersherum wird ein Schuh draus: Kannst Du eine Festlegung durch Abstimmung belegen? Üblicherweise steht sowas auf der Wikiseite in Form einer Abstimmung mit drauf (oder auf einer verwandten Wikiseite, die dann normalerweise verlinkt ist. kann nun von einer Festlegung wirklich nicht die Rede sein. Eine Festlegung kann auch ohne Abstimmung erfolgen. Es genügt eine Person. Klar - aber eine Festlegung durch eine Person ist wie die Befestigung eines 200kg-Bilderrahmens an einem einzigen kleinen Nagel: Man muss damit rechnen, dass das Bild wieder runterfällt oder die Festlegung eben nicht auf eine breite Mehrheit stößt. indem ich frage: Wo ist das denn FESTGELEGT? http://wiki.openstreetmap.org/wiki/Key:colour The value should be: * an RGB color code (hex triplet) ... * a CSS color name Die Vorgehensweise mit Proposal kennst Du aber? Ich weiß, sie ist nicht zwingend notwendig. Ich weiß auch, dass Proposals nur dadurch nicht zwingend besser werden oder eine höhere Relevanz genießen. Aber Ins Wiki schreiben kann jeder jederzeit beinahe alles, was er/sie/es will. Der colour-Tag ist so entsprechend dokumentiert worden, aber ob es sich dabei um eine Festlegung eine Meinung oder die Dokumentation der Verwendung durch einzelne handelt, ist zumindest nicht überprüfbar. Wenn dir eine Wiki-Seite reicht, kann ich dir gerne blödsinnige Wikiseiten suchen, die einfach niemanden im Detail interessieren, was der einzige Grund ist, warum sie nicht längst geändert oder gelöscht oder als abgestimmt und als abgelehnt dokumentiert markiert sind (siehe http://wiki.openstreetmap.org/wiki/Category:Proposed_features_%22Rejected%22 ). Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Datenmodell für Signalzeitenplan
Hallo, ich möchte Euch bitten den Vorschlag Traffic Lights Program http://wiki.openstreetmap.org/wiki/DE:Proposed_features/GLOSA auf der Diskussionsseite zu kommentieren/verbessern. Meine früheren Beiträge zum Thema: http://lists.openstreetmap.org/pipermail/talk-de/2013-February/100910.html http://forum.openstreetmap.org/viewtopic.php?id=20041 http://lists.openstreetmap.org/pipermail/talk/2013-May/067074.html Gruß Martin signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Am 05.06.2013 15:16, schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: und es keine Abstimmung gegeben hat (nichtmal eine kleine, wie es sie häufig gibt), Gibt es eine offizielle List über alle Abstimmungen anhand derer sich Deine Aussage überprüfen lässt? Andersherum wird ein Schuh draus: Kannst Du eine Festlegung durch Abstimmung belegen? Nein, daher hatte ich auch geschrieben Annahme: ... Du hast behauptet es hätte keine gegeben. kann nun von einer Festlegung wirklich nicht die Rede sein. Eine Festlegung kann auch ohne Abstimmung erfolgen. Es genügt eine Person. Klar - aber eine Festlegung durch eine Person ist wie die Befestigung eines 200kg-Bilderrahmens an einem einzigen kleinen Nagel: Man muss damit rechnen, dass das Bild wieder runterfällt oder die Festlegung eben nicht auf eine breite Mehrheit stößt. Definition in RGB existiert auf dieser Seite seit 2010 http://wiki.openstreetmap.org/w/index.php?title=Key:colouroldid=465809 brown, green, red, white, gray, blue, yellow, black haben laut http://taginfo.openstreetmap.org/keys/colour#values einen Anteil von mehr als 66% an den Tagwerten. Sie sind alle als CSS3 color unter http://www.w3.org/TR/css3-color/#svg-color aufgeführt. indem ich frage: Wo ist das denn FESTGELEGT? http://wiki.openstreetmap.org/wiki/Key:colour The value should be: * an RGB color code (hex triplet) ... * a CSS color name Die Vorgehensweise mit Proposal kennst Du aber? Nein. Aber ich sehe jetzt: http://wiki.openstreetmap.org/wiki/Creating_a_proposal Danke. Aber Ins Wiki schreiben kann jeder jederzeit beinahe alles, was er/sie/es will. OK. Der colour-Tag ist so entsprechend dokumentiert worden, aber ob es sich dabei um eine Festlegung eine Meinung oder die Dokumentation der Verwendung durch einzelne handelt, ist zumindest nicht überprüfbar. Zumindest nicht allein auf dieser Seite. Wenn dir eine Wiki-Seite reicht, kann ich dir gerne blödsinnige Wikiseiten suchen, die einfach niemanden im Detail interessieren, was der einzige Grund ist, warum sie nicht längst geändert oder gelöscht oder als abgestimmt und als abgelehnt dokumentiert markiert sind OK. Danke. Wenn ich http://wiki.openstreetmap.org/wiki/Keys The value [...] describes its accompanying key. sehe, glaube ich gern, dass solche Seiten existieren. colour=black Black beschreibt den Key colour? (siehe http://wiki.openstreetmap.org/wiki/Category:Proposed_features_%22Rejected%22 ). Diese sind ja immerhin als rejected kategorisiert. Also wenn Key:colour keine offizielle Beschreibung für den Key colour enthält, dann gibt es wohl keine? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
Am 05.06.2013 um 15:46 schrieb Peter Wendorff wendo...@uni-paderborn.de: Wenn dir eine Wiki-Seite reicht, kann ich dir gerne blödsinnige Wikiseiten suchen, die einfach niemanden im Detail interessieren, was der einzige Grund ist, warum sie nicht längst geändert oder gelöscht oder als abgestimmt und als abgelehnt dokumentiert markiert sind (siehe http://wiki.openstreetmap.org/wiki/Category:Proposed_features_%22Rejected%22 ). Wobei selbst ein Eintrag auf dieser Liste nicht immer eindeutig ist, z.B. hier: http://wiki.openstreetmap.org/wiki/Proposed_features/Incline Nur weil es damals 2007 noch nicht möglich war, 15 Leute zur Abstimmung zu bewegen, heißt das ja noch nicht, dass dieser Vorschlag auch in der Zwischenzeit von den Mappern abgelehnt wird: http://taginfo.openstreetmap.org/keys/incline Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
Tobias Conradi mail.2...@tobiasconradi.com wrote: Dir ist aber schon klar, dass es Eindeutigkeit in croudsourcing Projekten wie OSM sowieso nie geben wird? Nein. Dann solltest du Dir das dringend klarmachen, denn sonst kämpfst Du gegen Windmühlen? Ich finde das ja ehrlich gesagt alles massiv überspezifiziert. Einfach die Klartextnamen aus rgb.txt verwenden und gut iss. Wo befindet sich diese Datei um den Wahrheitsgehalt der Aussage überprüfen zu können? Auf einem brauchbaren Betriebssystem unter /etc/X11/rgb.txt http://en.wikipedia.org/wiki/X11_color_names Im wesentlichen sind das definierte sprechende Namen für RGB Farbwerte. Da das Web aus dem Unix Dunstkreis stammt wird das AFAIK auch in HTML so verwendet. Gruss Sven -- Der normale Bürger ist nicht an der TU Dresden und schreibt auch nicht mit mutt. (Ulli Kuhnle in de.comp.os.unix.discussion) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Linie endet an Gebiet
Hallo alle zusammen ! Ich bin gerade dabei mich in ins Kartenerstellen einzuarbeiten und habe ein Problem. Ich habe die Straße Stettiner Straße korrigiert udn erhalte von JOSM die Warnung: Linie endet an Gebiet Ich habe leider keine Ahnung wie ich das Problem lösen soll da ich nicht verstehe was hier kaputt sein soll. Ich bitte um Hilfe. Ort: 23669 Timmendorfer Strand, Königsberger Straße auf Stettiner Straße Grüße Zafe ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
Am 5. Juni 2013 16:42 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Im wesentlichen sind das definierte sprechende Namen für RGB Farbwerte. Interessanterweise ist in dieser Datei Silber und Grau dasselbe ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
2013/6/5 Sven Geggus li...@fuchsschwanzdomain.de: Tobias Conradi mail.2...@tobiasconradi.com wrote: Dir ist aber schon klar, dass es Eindeutigkeit in croudsourcing Projekten wie OSM sowieso nie geben wird? Nein. Dann solltest du Dir das dringend klarmachen, denn sonst kämpfst Du gegen Windmühlen? Nur wenn jede Kampf für eine Sache, der nicht mit einem Sieg endet ein Kampf gegen Windmühlen ist, läge ein solcher Kampf gegen Winmühlen vor, falls es nie zu Eindeutigkeit in crowdsourcing Projekten wie OSM kommt. Ich finde das ja ehrlich gesagt alles massiv überspezifiziert. Einfach die Klartextnamen aus rgb.txt verwenden und gut iss. Wo befindet sich diese Datei um den Wahrheitsgehalt der Aussage überprüfen zu können? Auf einem brauchbaren Betriebssystem unter /etc/X11/rgb.txt Auf einem von mir gebrauchten System nicht gefunden. http://en.wikipedia.org/wiki/X11_color_names Im wesentlichen sind das definierte sprechende Namen für RGB Farbwerte. OK. Wie wandelt man einen von einem Verkehrsunternehmen gegebenen CMYK-Wert in einen solchen sprechenden Namen um? Würfeln? Oder mit Hilfe einer eindeutigen Abbildung? Da das Web aus dem Unix Dunstkreis stammt wird das AFAIK auch in HTML so verwendet. Nicht laut dem Artikel http://en.wikipedia.org/wiki/X11_color_names -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linie endet an Gebiet
MVX m...@gulli.com wrote: Ich habe die Straße Stettiner Straße korrigiert udn erhalte von JOSM die Warnung: Linie endet an Gebiet Rechtklick auf den Fehler und Zoom auf Problem (oder ähnliche Formulierung), um die betroffenen Objekte zu sehen. Warnungen sind nur mögliche aber keine zwingenden Fehler und können übergangen werden. Offenbar waren die Programmierer von JOM der Meinung, dass an Gebieten endende Linien Fehlerpotential haben. Endet aber beispielsweise ein Fußweg am Eingang eines Gebäudes, so ist da nichts zu bemängeln. Wäre es eine Autobahn, wird das Ganze schon fraglicher. Genaueres kann hier nur gesagt werden, wenn Du die IDs der betroffenen Objekte nennst. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
Tobias Conradi mail.2...@tobiasconradi.com wrote: Auf einem von mir gebrauchten System nicht gefunden. Na ja, auf Windows gibts das nicht, aber jedes Unix mit X11 hat das irgendwo. OK. Wie wandelt man einen von einem Verkehrsunternehmen gegebenen CMYK-Wert in einen solchen sprechenden Namen um? Ehrlich gesagt ist mir das völlig egal, denn OSM hat wirklich wichtigere Probleme zu lösen als dieses obskure Nieschenthema von ÖPNV Farben die ohnehin nicht mal jeder verwendet. Daher ist das mein letzes Posting zu diesem Thema. Da das Web aus dem Unix Dunstkreis stammt wird das AFAIK auch in HTML so verwendet. Nicht laut dem Artikel http://en.wikipedia.org/wiki/X11_color_names Aha, wo wir also schon beim haare Spalten sind: The first versions of Mosaic and Netscape Navigator used the X11 colors as the basis for the Web colors list Leider erläutert der Artikel some changes nicht näher. Ich habe aber in der Praxis noch keine Unterschiede zwischen CSS und rgb.txt festgestellt. Gruss Sven -- We just typed make (Stephen Lambrigh, Director of Server Product Marketing at Informix about porting their Database to Linux) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linie endet an Gebiet
Hi, du meinst das hier? http://www.openstreetmap.org/?lat=53.988759lon=10.766189zoom=18layers=M In der aktuellen Fassung ist hier nichts falsch. Was hast du denn geändert? erhalte von JOSM die Warnung: Linie endet an Gebiet Diese Meldung bedeutet, dass die Straße mit einem landuse oder anderen Fläche verbunden ist, die kein highway=* ist. Hmm.. Wenn ich mir das BING -Bild hier anschaue ist das landuse=gras der Fläche entlang der Danziger Allee falsch, das sind doch offenbar Parkplätze und Bäume. Gruß, Micha. On Wednesday 05 June 2013 16:51:35 MVX wrote: Hallo alle zusammen ! Ich bin gerade dabei mich in ins Kartenerstellen einzuarbeiten und habe ein Problem. Ich habe die Straße Stettiner Straße korrigiert udn erhalte von JOSM die Warnung: Linie endet an Gebiet Ich habe leider keine Ahnung wie ich das Problem lösen soll da ich nicht verstehe was hier kaputt sein soll. Ich bitte um Hilfe. Ort: 23669 Timmendorfer Strand, Königsberger Straße auf Stettiner Straße Grüße Zafe ___ 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] Linie endet an Gebiet
Ahh okay, dann scheint ja alles gut zu sein. Vielen Dank schon einmal. Hier trotzdem nochmal die IDs: * 36775954 * 136489404 Grüße Zafe Am 05.06.2013 17:53, schrieb Tirkon: MVX m...@gulli.com wrote: Ich habe die Straße Stettiner Straße korrigiert udn erhalte von JOSM die Warnung: Linie endet an Gebiet Rechtklick auf den Fehler und Zoom auf Problem (oder ähnliche Formulierung), um die betroffenen Objekte zu sehen. Warnungen sind nur mögliche aber keine zwingenden Fehler und können übergangen werden. Offenbar waren die Programmierer von JOM der Meinung, dass an Gebieten endende Linien Fehlerpotential haben. Endet aber beispielsweise ein Fußweg am Eingang eines Gebäudes, so ist da nichts zu bemängeln. Wäre es eine Autobahn, wird das Ganze schon fraglicher. Genaueres kann hier nur gesagt werden, wenn Du die IDs der betroffenen Objekte nennst. ___ 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] Linie endet an Gebiet
Am 05.06.2013 16:51, schrieb MVX: Hallo alle zusammen ! Ich bin gerade dabei mich in ins Kartenerstellen einzuarbeiten und habe ein Problem. Ich habe die Straße Stettiner Straße korrigiert udn erhalte von JOSM die Warnung: Linie endet an Gebiet Ich habe leider keine Ahnung wie ich das Problem lösen soll da ich nicht verstehe was hier kaputt sein soll. Ich bitte um Hilfe. Ort: 23669 Timmendorfer Strand, Königsberger Straße auf Stettiner Straße Grüße Zafe ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hallo Zafe, nimm nachfolgendes Video als Anleitung, um unerwünschte Linien aus zu filtern: * O http://youtu.be/zGT3Eco6vZASM Tutorial No 02 - Die OpenStreetMap-Karte in JOSM übersichtler machen (Linien filtern) http://youtu.be/zGT3Eco6vZA Gruß -Franz- weitere Videos von Skobbler gitbt es *hier* https://www.youtube.com/user/tutorialsbyskobbler ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linie endet an Gebiet
Hallo, Am Mittwoch, den 05.06.2013, 16:51 +0200 schrieb MVX: Hallo alle zusammen ! Ich bin gerade dabei mich in ins Kartenerstellen einzuarbeiten und habe ein Problem. Ich habe die Straße Stettiner Straße korrigiert udn erhalte von JOSM die Warnung: Linie endet an Gebiet Ich habe leider keine Ahnung wie ich das Problem lösen soll da ich nicht verstehe was hier kaputt sein soll. Ich bitte um Hilfe. Ort: 23669 Timmendorfer Strand, Königsberger Straße auf Stettiner Straße es ist für alle hilfreich, wenn du die ID-Nummer mindestens eines der Objekte angibst oder wenigstens einen Perma-Link im Mapnik. Ich habe die Stelle gefunden. Es ist alles in Ordnung, wenngleich die Grünfläche innerhalb der Danziger Allee nicht unbedingt im Mainstream getaggt ist. Die Grünfläche (Gebiet) wird auf 3 Seiten durch die Danziger Allee und auf der Südseite durch die Stettiner Straße begrenzt. Es ist eigentlich in Fehler in der Fehlerprüfung von josm, der erkennen sollte, dass es sehr wohl einen weiterführenden Weg gibt. In dem Fall sollte er das Gebiet unbeachtet lassen. Ca. 80% der Warnungen von josm kann man getrost wegklicken, aber der Anfänger weiß natürlich nicht, welche... Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linie endet an Gebiet
Okay, dann liegt das Problem nur daran das die Straße an einer landuse Fläche grenzt. Die Karte an der Stelle müsste mal detaillierter werden. In Wirklichkeit ist das eine Rasenfläche mit Bäumen und 2 Parkflächen für ein paar Autos. Immerhin sind die Straßen nun schon einmal die richtigen. @ Franz-Josef Rüther: Danke für die Videos ! Sind Hilfreich Grüße Zafe Am 05.06.2013 18:02, schrieb Michael Hufer: Hi, du meinst das hier? http://www.openstreetmap.org/?lat=53.988759lon=10.766189zoom=18layers=M In der aktuellen Fassung ist hier nichts falsch. Was hast du denn geändert? erhalte von JOSM die Warnung: Linie endet an Gebiet Diese Meldung bedeutet, dass die Straße mit einem landuse oder anderen Fläche verbunden ist, die kein highway=* ist. Hmm.. Wenn ich mir das BING -Bild hier anschaue ist das landuse=gras der Fläche entlang der Danziger Allee falsch, das sind doch offenbar Parkplätze und Bäume. Gruß, Micha. On Wednesday 05 June 2013 16:51:35 MVX wrote: Hallo alle zusammen ! Ich bin gerade dabei mich in ins Kartenerstellen einzuarbeiten und habe ein Problem. Ich habe die Straße Stettiner Straße korrigiert udn erhalte von JOSM die Warnung: Linie endet an Gebiet Ich habe leider keine Ahnung wie ich das Problem lösen soll da ich nicht verstehe was hier kaputt sein soll. Ich bitte um Hilfe. Ort: 23669 Timmendorfer Strand, Königsberger Straße auf Stettiner Straße Grüße Zafe ___ 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] Widersprüche zwischen Wiki-Definition und Mapnik-Rendering
Am 05.06.2013 01:47, schrieb Martin Koppenhoefer: Das Problem ist, wie osm2pgsql arbeitet, man kann nur keys als Fläche zuordnen, aber nicht k/v-Paare, d.h. im Zweifel wird man eher ein Liniendefault setzen und nur mit area=yes auf Fläche gehen, weil sonst so was wie bei leisure=track passiert (leisure wird immer als area angesehen). Als Lösung kann man auf einen Area-Datentyp hoffen, oder darauf, dass man auch k/v-Kombinationen in osm2pgsql styles definieren kann. Oder z.B. einen anderen Importer verwenden, Imposm kann das vielleicht? Danke für die schnelle Antwort. Es war mir nicht klar, dass osm2pgsql diese Einschränkung hat. Es ist schade, dass ein Tool, welches für die Hauptkarte wichtig ist, die elementaren Definitionen nicht korrekt umsetzen kann. Trotzdem sollte es doch möglich sein, Objekte wie highway=services, highway=rest_area und railway=station, die in der line-Datenbanktabelle landen, aber nur als Fläche definiert sind, auch als Fläche zu rendern. Für leisure=track könnte man trotz Flächenzuordnung nur die Außenlinie ohne Füllung malen. Dann hätte man trotz der falschen Zuordnung durch osm2pgsql eine korrekte Kartendarstellung. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
Am 05.06.2013 16:26, schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Am 05.06.2013 15:16, schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: und es keine Abstimmung gegeben hat (nichtmal eine kleine, wie es sie häufig gibt), Gibt es eine offizielle List über alle Abstimmungen anhand derer sich Deine Aussage überprüfen lässt? Andersherum wird ein Schuh draus: Kannst Du eine Festlegung durch Abstimmung belegen? Nein, daher hatte ich auch geschrieben Annahme: ... Du hast behauptet es hätte keine gegeben. Um mal dein Selbst-Zitat zu vervollständigen: Annahme: Vor der Festlegung von RGB wurde RGB vorgeschlagen. Schlußfolgerung: Auch das Vorschlagen von RGB ist schon geschehen. Du definierst etwas als Festlegung unter der Annahme, es hätte vorher einen Vorschlag gegeben. Fakt ist eine Wiki-Seite, die weder als Vorschlag noch als abgestimmte Festlegung deklariert (geschweige denn belegt ist). In OSM ist üblich: - Einfach mal machen (ohne Dokumentation) - Dokumentation dessen, was da, aber noch nicht dokumentiert ist - Proposal mit dem Ablauf: - Draft: Entwurfszeit - RFC: Nach Meinungen fragen - das iteriert dann beliebig häufig, wenn Meinungen, Kommentare, Vorschläge eingearbeitet werden - Abstimmung - evtl. trotzdem nochmal Rücksetzung bei neuen Einwänden/Vorschlägen... - Annahme durch Abstimmen oder - Ablehnung durch Abstimmen, dann oft zurück auf einen der vorigen Schritte. Alle diese Schritte manifestieren sich üblicherweise auf der/einer Wiki-Seite, da die Bearbeitung derselben das Mittel der Wahl zur Stimmabgabe und die Bearbeitung der zugehörigen Talk-Seite eines der Mittel für Meinungen und Kommentare dazu ist. In diesem Fall fehlt eine Diskussion auf der Talk-seite genauso wie ein Proposal-Template, eine Abstimmung oder sonstwas in der Art. Eine Festlegung durch ich lege eine Seite an und die Seite wird durch niemanden beanstandet ist glaub ich bei der Mehrheit nicht akzeptabel - sobald jemand das als Fakt und Festlegung heranziehen will, um Regeln daraus abzuleiten. Als Dokumentation und Diskussionsgrundlage für eine spätere Einigung immer und gerne - aber eben nicht als Regel/Gesetz. Der colour-Tag ist so entsprechend dokumentiert worden, aber ob es sich dabei um eine Festlegung eine Meinung oder die Dokumentation der Verwendung durch einzelne handelt, ist zumindest nicht überprüfbar. Zumindest nicht allein auf dieser Seite. Wenn dir eine Wiki-Seite reicht, kann ich dir gerne blödsinnige Wikiseiten suchen, die einfach niemanden im Detail interessieren, was der einzige Grund ist, warum sie nicht längst geändert oder gelöscht oder als abgestimmt und als abgelehnt dokumentiert markiert sind OK. Danke. Wenn ich http://wiki.openstreetmap.org/wiki/Keys The value [...] describes its accompanying key. sehe, glaube ich gern, dass solche Seiten existieren. colour=black Black beschreibt den Key colour? Schwarz beschreibt die Farbe, ja. Ein Haus hat eine Farbe (hat den key color), und Wie ist die Farbe? Schwarz! = Schwarz beschreibt die Eigenschaft Farbe. (siehe http://wiki.openstreetmap.org/wiki/Category:Proposed_features_%22Rejected%22 ). Diese sind ja immerhin als rejected kategorisiert. Also wenn Key:colour keine offizielle Beschreibung für den Key colour enthält, dann gibt es wohl keine? So ungefähr. Das muss ja auch nicht heißen, dass das falsch ist, es muss nichtmal unbedingt heißen, dass deine Meinung dazu falsch ist (die sich zufällig auch aus dem aktuellen Text im Wiki herleiten lässt), aber es heißt eben auch nicht unbedingt, dass das so feststehend die Regel ist. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
2013/6/5 Sven Geggus li...@fuchsschwanzdomain.de: Tobias Conradi mail.2...@tobiasconradi.com wrote: OK. Wie wandelt man einen von einem Verkehrsunternehmen gegebenen CMYK-Wert in einen solchen sprechenden Namen um? Ehrlich gesagt ist mir das völlig egal, Dann ist Deine Abbildung im Gegensatz zu der von mir vorgeschlagenen nicht eindeutig. Eine allgemein als Lila bekannte Linie könnte bei Dir den Wert 00 http://www.colorcombos.com/colors/00 -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmodell für Signalzeitenplan
Martin Schafran mar...@ampelmeter.com wrote: ich möchte Euch bitten den Vorschlag Traffic Lights Program http://wiki.openstreetmap.org/wiki/DE:Proposed_features/GLOSA auf der Diskussionsseite zu kommentieren/verbessern. Meine früheren Beiträge zum Thema: http://lists.openstreetmap.org/pipermail/talk-de/2013-February/100910.html http://forum.openstreetmap.org/viewtopic.php?id=20041 http://lists.openstreetmap.org/pipermail/talk/2013-May/067074.html Sorry, aber das ist vollkommen unbrauchbar für OSM, da von der großen Mehrheit der Mapper nicht umsetzbar. Wir haben mit den ÖPNV Schemata prominente Vertreter, wo das Ganze auch nicht funktioniert. Der ÖPNV wird inzwischen in unzähligen Varianten gemappt und verbrennt dabei jede Menge Tags. Möglicherweise kann man solche aufwendigen Konstrukte in einer Firma mit entsprechend vorgebildeten und auf die Konzepte geschulten Mitarbeitern einführen. Aber in einer Community wie OSM haben sie IMHO nichts zu suchen. Wenn man schon über etwas abstimmen lässt, sollte man wenigstens darüber nachdenken, dass nicht nur die kleine Gruppe der Diskutanten, sondern auch Tausende fachfremde Mapper dies umsetzen sollen, die keinerlei Informatik- oder Mathematikausbildung genossen haben. Aber ohne diese Mapper funktioniert OSM nicht. Zudem werden hier unnötigerweise Bezeichnungen für Tags und damit Ressourcen verbrannt, die an anderer Stelle nicht mehr zur Verfügung stehen. Außerdem ist das Wiki dann bald eine Müllhalde voller Fast-Leichen-Proposals, deren punktuelle Anwendung in der Datenbank lediglich darauf stoßende Mapper abschreckt, wenn sie einfache Änderungen deswegen nicht mehr durchführen können. Ja ich weiß: OSM ist frei und jeder soll in die OSM eintragen, was er möchte. Aber wenn die Betätigung Weniger zu einer Behinderung Vieler führt, muss über die Verteilung der Ressourcen nachgedacht werden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] osm website: Schnellsuche Firefox
Aus irgend einem Grund funktioniert es nicht mit Firefox eine Schnellsuche für
OSM anzulegen. Das ist schade, ich würde gerne in die adresszeile osm
{adresse} ingeben können und dann gleich zur ergebnisseite zu gelangen.
für nicht firefox user: über die schnellsuche (kontextmenü auf ein
formularfeld) lassen sich shortcuts anlegen, die man dann direkt in die
adresszeile eingeben kann.
m.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung
On 05.06.2013 17:53, Sven Geggus wrote: Leider erläutert der Artikel some changes nicht näher. Doch, in der Tabelle der Farbnamen findet man die Unterschiede: Gray, Green, Maroon und Purple sind beim W3C anders definiert als bei X11 und die Farben Lime und Silver gibt es nur beim W3C. Gruß, Mark ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Am 05.06.2013 16:26, schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: Am 05.06.2013 15:16, schrieb Tobias Conradi: 2013/6/5 Peter Wendorff wendo...@uni-paderborn.de: und es keine Abstimmung gegeben hat (nichtmal eine kleine, wie es sie häufig gibt), Diese Behauptung ist immer noch unbelegt. Kannst Du eine Festlegung durch Abstimmung belegen? Nein, daher hatte ich auch geschrieben Annahme: ... Du hast behauptet es hätte keine gegeben. Um mal dein Selbst-Zitat zu vervollständigen: Annahme: Vor der Festlegung von RGB wurde RGB vorgeschlagen. Schlußfolgerung: Auch das Vorschlagen von RGB ist schon geschehen. Du definierst etwas als Festlegung unter der Annahme, es hätte vorher einen Vorschlag gegeben. Nein. Fakt ist eine Wiki-Seite, die weder als Vorschlag noch als abgestimmte Festlegung deklariert (geschweige denn belegt ist). OK. Da steht also im offiziellen OSM Wiki The value should be: ..., es ist aber nicht belegt, dass dies stimmt. In OSM ist üblich: - Einfach mal machen (ohne Dokumentation) - Dokumentation dessen, was da, aber noch nicht dokumentiert ist - Proposal mit dem Ablauf: - Draft: Entwurfszeit - RFC: Nach Meinungen fragen - das iteriert dann beliebig häufig, wenn Meinungen, Kommentare, Vorschläge eingearbeitet werden - Abstimmung - evtl. trotzdem nochmal Rücksetzung bei neuen Einwänden/Vorschlägen... - Annahme durch Abstimmen oder - Ablehnung durch Abstimmen, dann oft zurück auf einen der vorigen Schritte. Alle diese Schritte manifestieren sich üblicherweise auf der/einer Wiki-Seite, da die Bearbeitung derselben das Mittel der Wahl zur Stimmabgabe und die Bearbeitung der zugehörigen Talk-Seite eines der Mittel für Meinungen und Kommentare dazu ist. Ausser Schritt 1. In diesem Fall fehlt eine Diskussion auf der Talk-seite genauso wie ein Proposal-Template, eine Abstimmung oder sonstwas in der Art. Vielleicht ist es noch ein Schritt, den Du nicht kanntest. http://wiki.openstreetmap.org/wiki/Proposed_features This page describes the proposal process, which is one of multiple ways to introduce [...] new features. Eine Festlegung durch ich lege eine Seite an und die Seite wird durch niemanden beanstandet ist glaub ich bei der Mehrheit nicht akzeptabel - sobald jemand das als Fakt und Festlegung heranziehen will, um Regeln daraus abzuleiten. Als Dokumentation und Diskussionsgrundlage für eine spätere Einigung immer und gerne - aber eben nicht als Regel/Gesetz. Da ist ein Text, der sagt seit 2010 should. Und hinter should kommt nie etwas anders als ein sRGB Wert. Das war's. Es kann ein Witz sein den sich jemand erlaubt, es kann irgendwas sein. Eine Festlegung soll es aber nicht sein. Dafür was eine Festlegung sein soll, wurde keine offizielle OSM Seite zitiert. Dann nehm ich mal den Duden http://www.duden.de/rechtschreibung/Festlegung Synonyme: Aufstellung, Bestimmung, Ordnung, Regel should be ist für mich eindeutig eine Festlegung, Bestimmung, Regel. Wenn ich http://wiki.openstreetmap.org/wiki/Keys The value [...] describes its accompanying key. sehe, glaube ich gern, dass solche Seiten existieren. colour=black Black beschreibt den Key colour? Schwarz beschreibt die Farbe, ja. Ein Haus hat eine Farbe (hat den key color), und Wie ist die Farbe? Schwarz! = Schwarz beschreibt die Eigenschaft Farbe. Wenn kein Objekt angegeben ist, dann lautet die Antwort auf die Frage, wie ist die Farbe: Einer von 3247 Werten. Quelle: http://taginfo.openstreetmap.org/keys/colour#overview Black ist nur bedingt korrekt, somit keine Beschreibung des Keys. Also wenn Key:colour keine offizielle Beschreibung für den Key colour enthält, dann gibt es wohl keine? So ungefähr. Das muss ja auch nicht heißen, dass das falsch ist, es muss nichtmal unbedingt heißen, dass deine Meinung dazu falsch ist (die sich zufällig auch aus dem aktuellen Text im Wiki herleiten lässt), aber es heißt eben auch nicht unbedingt, dass das so feststehend die Regel ist. Das es zur Zeit die Regel ist ergibt sich aus http://taginfo.openstreetmap.org/keys/colour#values Ich sehe nur Werte wie sie hinter should be angegeben sind. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osm website: Schnellsuche Firefox
Versuch mal das entsprechende Lesezeichen manuell auf
http://www.openstreetmap.org/?query=%s; zu setzen (statt
http://www.openstreetmap.org/geocoder/search;).
PS: Das gleiche Feature gibt es auch im Opera - super praktisch!
Am 05.06.2013, 18:47 Uhr, schrieb Max abonneme...@revolwear.com:
Aus irgend einem Grund funktioniert es nicht mit Firefox eine
Schnellsuche für OSM anzulegen. Das ist schade, ich würde gerne in die
adresszeile osm {adresse} ingeben können und dann gleich zur
ergebnisseite zu gelangen.
für nicht firefox user: über die schnellsuche (kontextmenü auf ein
formularfeld) lassen sich shortcuts anlegen, die man dann direkt in die
adresszeile eingeben kann.
m.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
Am 05.06.2013 19:17, schrieb Tobias Conradi: In diesem Fall fehlt eine Diskussion auf der Talk-seite genauso wie ein Proposal-Template, eine Abstimmung oder sonstwas in der Art. Vielleicht ist es noch ein Schritt, den Du nicht kanntest. http://wiki.openstreetmap.org/wiki/Proposed_features Jetzt führst du eine Quelle an die deine Aussage nichtmal stützt? Ich sehe da für ein Proposal die Schritte: Draft, Proposed, Voting, Approved or rejected, Post-vote clean-up Schon beim Draft wird das Proposal-Template (mit Status Draft) eingefügt, das dann auch bleibt bis zum Approved/rejected. Im Post-Vote wird die Proposal-Seite so gelassen und die Key-Page hinzugefügt, die beiden Seiten sollten dabei in beide Richtungen verlinkt werden - was hier nicht geschehen ist. Und nicht nur fehlt der Link, ich kann die Proposal-Seite auch sonst nirgendwo finden. Also: - Draft, proposed, Voting, Approved und rejected müssten demnach dann ein Proposal_template haben, - Post-vote müsste einen Link zu einem Proposal mit dem Status approved oder rejected haben. Da das jeweils fehlt, weiß ich nicht, welchen Schritt du meinst, den ich übersehen haben sollte. This page describes the proposal process, which is one of multiple ways to introduce [...] new features. Stimmt. Aber to introduce a feature ist nicht Ein Merkmal FESTLEGEN, sondern ein Merkmal EINFÜHREN, und eine Einführung ohne Abstimmung etc. ist eben keine Festlegung, auf die irgendjemand sich beziehen sollte, um seine Meinung durchzusetzen (zu argumentieren ja, daraus zwingend durchzusetzen nein). Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osm website: Schnellsuche Firefox
Super, danke! Funktioniert :) Gruß René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr. 150 28.5.-3.6.2013
Hallo, die Wochennotiz Nr. 150 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/2013/06/wochennotiz-nr-150/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmodell für Signalzeitenplan
Am Mittwoch, den 05.06.2013, 18:36 +0200 schrieb Tirkon: Martin Schafran mar...@ampelmeter.com wrote: ich möchte Euch bitten den Vorschlag Traffic Lights Program http://wiki.openstreetmap.org/wiki/DE:Proposed_features/GLOSA auf der Diskussionsseite zu kommentieren/verbessern. Meine früheren Beiträge zum Thema: http://lists.openstreetmap.org/pipermail/talk-de/2013-February/100910.html http://forum.openstreetmap.org/viewtopic.php?id=20041 http://lists.openstreetmap.org/pipermail/talk/2013-May/067074.html Sorry, aber das ist vollkommen unbrauchbar für OSM, da von der großen Mehrheit der Mapper nicht umsetzbar. Wir haben mit den ÖPNV Schemata prominente Vertreter, wo das Ganze auch nicht funktioniert. Der ÖPNV wird inzwischen in unzähligen Varianten gemappt und verbrennt dabei jede Menge Tags. Möglicherweise kann man solche aufwendigen Konstrukte in einer Firma mit entsprechend vorgebildeten und auf die Konzepte geschulten Mitarbeitern einführen. Aber in einer Community wie OSM haben sie IMHO nichts zu suchen. Wenn man schon über etwas abstimmen lässt, sollte man wenigstens darüber nachdenken, dass nicht nur die kleine Gruppe der Diskutanten, sondern auch Tausende fachfremde Mapper dies umsetzen sollen, die keinerlei Informatik- oder Mathematikausbildung genossen haben. Aber ohne diese Mapper funktioniert OSM nicht. Zudem werden hier unnötigerweise Bezeichnungen für Tags und damit Ressourcen verbrannt, die an anderer Stelle nicht mehr zur Verfügung stehen. Das mit der tag-Verbrennung sehe ich eigentlich nicht so. Die sind doch reichlich speziell, da verirrt sich so leicht keiner in den Namensraum. Ansonsten +1 Ich halte das Ganze schon von der Idee her für Unsinn. Vor 15 Jahren hätte man so etwas machen können, wenn man die Technik gehabt hätte. Heute haben wir die Technik, aber die Ampeln werden zu kompliziert. In der Sache dürfte das so zuverlässig sein, wie der Wetterbericht um 1970. Die Feuerwehr pumpte einen halben Meter heiter bis wolkig aus dem Keller :-) Die Ampeln werden immer mehr von der Verkehrslage, öffentlichen Verkehrsmitteln, der Feuerwehr, Staatsbesuchern und weiß der Himmel noch wem gesteuert. Sogar für Regenwetter und Schneefall gibt es Anpassungen. Selbst mit direktem Zugriff auf die Software dürfte eine Vorhersage heute schon fraglich, aber in naher Zukunft reine Kaffeesatzleserei sein. Sinnvoller wäre eine Art Vorsignal. Wenn du jetzt Tempo 48 hälst, hast du an der nächsten Ampel grün. Das müsste aber an der Straße stehen und vom Ampelrechner gesteuert werden. So was gab es sogar schon mal. Alles andere hört sich schön an, funktioniert aber nur noch, wenn überhaupt, an einer abnehmenden Zahl von Ampeln. Unabhängig davon schlage ich vor, das als separates Projekt außerhalb von OSM zu machen. Durch die TMC-Geschichte haben wir genügend tags, um die Ampeln zu referenzieren. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Widersprüche zwischen Wiki-Definition und Mapnik-Rendering
On 05/giu/2013, at 18:26, Stephan Wolff s.wo...@web.de wrote: Trotzdem sollte es doch möglich sein, Objekte wie highway=services, highway=rest_area und railway=station, die in der line-Datenbanktabelle landen, aber nur als Fläche definiert sind, auch als Fläche zu rendern. wenn area=yes getaggt ist sollte das so sein dass sie als Fläche gerendert werden Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wochennotiz Nr. 150 28.5.-3.6.2013
On Wed, 5 Jun 2013, Gehling Marc wrote: Hallo, die Wochennotiz Nr. 150 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/2013/06/wochennotiz-nr-150/ Viel Spaß beim Lesen! Vielen Dank, hatte ich! Ich denke ich spreche fuer die OSM Community wenn ich behaupte, dass die Wochennotizen seit langer Zeit ein informativer und gut aufbereiteter News-Aggregator sind. Dickes Lob! Das Thema zum Artikel 'Hausnummern mappen und Internetverweigerer' kommt sicher einigen bekannt vor. Ich bin diesbezueglich deshalb auch gerade wieder mal dabei, ein wenig PR Arbeit anzustossen. Konkret, den OSM Flyer zu ueberarbeiten und mit etwas frischem, weniger 'nerdigem' Text aufzupeppen. @Frederik: Dein Flyer war und ist ne super Vorlage und ich hoffe Du verstehst diese Wortwahl als positives Feedback ;) Ich denke wir sind an vielen Orten - wie im Artikel beschrieben - an einem Punkt angekommen, wo die Leute neugierig, nervoes oder abweisend reagieren. Weil eben immer mehr Details bis an die Grundstuecksgrenze gemapped werden. Stichwort Google Streetview und die Presse darueber, etc. Diese Hemmschwelle zu ueberschreiben und das mit ein paar Zeilen auf einem Flyer zu kommunizieren ist nicht einfach. Deshalb: Wenn jemand in diesem Bereich der 'Aufklaerungsarbeit' noch Erfahrungen beisteuern kann, dann taete mich das interessieren. Merci - A.___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wochennotiz Nr. 150 28.5.-3.6.2013
Wäre es vlt. möglich und sinnvoll den neuen Text im Forum zur Diskussion zu stellen und zur Mitarbeit aufzufordern? Ich denke, es wird sicherlich ein großes Durcheinander geben, den viele Köche verderben bekanntlich den Brei ;-) Aber die eine oder andere Idee oder Anmerkung wird garantiert dabei heraus kommen... Gruß René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Piazza e parcheggio
Se ho capito bene la cosa migliore e' asssegnare i tag di scuola, chiesa, municipio, ... all'intero edificio se entita' ed edificio corrispondono e utilizzare un nodo altrimenti (edificio con piu' negozi, per esempio). E' giusto? sì, è corretto così. Siccome quel'edificio chiesa e adibito interamente ad un solo scopo, consiglio di togliere il nodo e di mettere i suoi tag all'intero edificio. Per gli edifici con più di un negozio o anche numero civico io solitamente metto dei nodi facenti parte della way perimetro dell'edificio e assegno i singoli tag a questi...non so se sia il metodo corretto, ma ho visto che è così che fanno i francesi su osm. Avevo guardato come era stata mappata un'altra piazza del paese: totalmente scollegata dagli edifici circostanti. Ora ho collegato tre lati delle piazze con gli edifici adiacenti, lasciando libero solo quello verso la strada: anche questo dovrebbe essere collegato? solitamente si fa così...se la piazza termina sulla strada e in mezzo non c'è nulla la piazza viene collegata con la strada. se anche dall'altra parte della piazza vi è una zona pedonale allora la piazza prosegue oltre facendo comunque in modo che la strada e il perimetro della piazza abbiano un nodo in comune nei punti in cui si incrociano. ogni tanto può capitare che le strade siano particolarmente larghe e che quindi il limite pedonale della piazza sia parecchio distante dalla center line della strada (su cui dovrebbe giacere la way ) e alcuni, me compreso, preferiscono non unire la piazza alla strada (naturalmente facendo poi gli opportuni collegamenti) altri invece mappano comunque con il lato in comune piazza-strada. -- View this message in context: http://gis.19327.n5.nabble.com/Piazza-e-parcheggio-tp5763898p5764033.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] OT: ENELsharing
Sembra che l'azienda sia un po' spregiudicata nell'uso dei Social network. http://www.domitillaferrari.com/semerssuaq/ditelo-a-quelli-del-marketing-di-enel/ ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: Mappare turbine idroelettriche.
Se verra' approvata la proposta, ho notato che power=station viene implicitamente deprecata e va sostituita da power=sub_station. Siccome ho mappato circa un migliaio di stazioni elettriche di trasformazione nel nord Italia, mi chiedevo se devo ritaggarmele tutte. Saluti Fabrizio Suppongo di si se vogliamo mantenere il database coerente. Non dovrebbe essere difficile recuperare quelle che hai inserito e ritaggarle tutte in blocco. Con Taginfo ad esempio si può cercare un tag e caricare i risultati direttamente in JOSM per modificarli. Solo che nel caso di power=station restituisce troppi risultati per tutto il mondo e non funziona. Qualcuno con più esperienza di me conosce un modo per cercare tutti i tag power=station in una certa area, meglio ancora se inseriti da un certo utente? Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: Mappare turbine idroelettriche.
Il giorno 05 giugno 2013 17:16, Alberto albertoferra...@fastwebnet.it ha scritto: Con Taginfo ad esempio si può cercare un tag e caricare i risultati direttamente in JOSM per modificarli. Solo che nel caso di power=station restituisce troppi risultati per tutto il mondo e non funziona. Qualcuno con più esperienza di me conosce un modo per cercare tutti i tag power=station in una certa area, meglio ancora se inseriti da un certo utente? Grazie per il commento. Per cercare i tag power=station in un'area con JOSM puoi vedere come ha fatto Cascafico nel suo blog: http://cascafico.altervista.org/index.php?option=com_contentview=articleid=26:caccia-al-tesorocatid=3:josmItemid=17 Saluti Fabrizio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-co] Vandalismo en Cartagena
Con el complemento reverter en JOSM hay que deshacer los conjuntos de cambios uno por uno desde el más reciente hasta el más antiguo. La cosa se complica si los objetos han sido tocados en el ínterin. En ese caso se debe hacer un poco de trabajo manual :( 2013/6/5 hyan...@gmail.com hyan...@gmail.com Hola, Bien, he conversado con el usuario, resulta que estaba usando una imagen de Google (dic.09) para realizar sus ediciones, hemos concertado, por lo cual haré las reversiones de los chagesets que afectaron la cartografía actualizada con base en imagen Bing (feb.12). Se comprometió con estudiar la licencia de OSM y espero ya esté suscrito a la lista, el mejor espacio de aprendizaje para este proyecto de construcción comunitaria y colaborativa. Ofrezco mis disculpas por la alarma, es una situación nueva para mi y debo confesar que me asalta un fuerte celo al observar afectaciones sobre las ediciones de muchas noches y otros colaboradores. Intenté hacer las reversiones por el JOSM pero aparece un error... Estoy ahora adivinando los parámetros de los scripts, le agradezco a quién conozca sobre ellos su ayuda por el interno en hyan...@gmail.com Saludos, Humberto Yances El 1 de junio de 2013 19:22, hyan...@gmail.com hyan...@gmail.comescribió: Estimados maper@s: Tengo un caso de vandalismo [1] para Cartagena. Proviene desde el usuario Jhonfac, sus actos de vandalismo se concentran en: 1) descuadrar los vectores del mapa moviendo los nodos de las intersecciones entre las vías; 2) eliminar vectores de vías; Estas son sus ediciones: http://www.openstreetmap.org/user/Johnfac/edits Apelo a la lista para su colaboración, ya que he escrito al usuario sin tener una respuesta a las peticiones para corregir los datos afectados. Me encuentro editando con JOSM los nodos y rehaciendo vías; pero preferiría revertir sus ediciones que ha realizado en Cartagena. Agradezco su colaboración para el apoyo en el proceso de rollback [2]. Mil gracias, Humberto Yances [1] http://wiki.openstreetmap.org/wiki/Vandalism [2] http://wiki.openstreetmap.org/wiki/Change_rollback ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co -- In a world without walls or fences, who needs windows and gates? ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
[Talk-cz] Smoothness map
Tak MTB mapu uz mame, chybela mi nejaka mapa pro silnicni cyklisty, cili mapa kvality cest, tak sem se pokusil neco jednoducheho vytvorit. Stahl jsem aktualni data CR z http://osm.kyblsoft.cz pak sem to prohnal pres Osmfilter http://wiki.openstreetmap.org/wiki/Osmfilter a ulozil do jednotlivych .osm souboru pomoci nejakych takovych prikazu ./osmfilter czech_republic-2013-06-04.osm --keep=smoothness=excellent -o=cr_excellent.osm Nechal sem tam jen smoothness excellent,good,intermediate, bad a very_bad, tyto soubory jsem vlozil pomoci OpenLayers a barevne odlisil, tady je vysledek: http://kraken.php5.cz/ Zatim tam toho moc neni, takze jen co prestane prset tak je potreba zacat jezdit, vsimat si povrchu a pak se o to podelit prostrednictvim OSM. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Prosba o kontrolu navsi
Dne 4.6.2013 21:20, jzvc napsal(a): Dne 4.6.2013 14:28, Dalibor Jelínek napsal(a): Ahoj, je moz(ný, z(e jsem natvrdlej, protoz(e nechápu to s tou navigací dokola. V tomhle mým pr(ípade( je to teda ude(laný dobr(e? http://www.openstreetmap.org/browse/way/224077225 Cesty jsem s area nespojoval a ani jsem je nepr(erus(oval. Proste( jsem je nechal kr(íz(it tu area a ignoroval varování JOSM. Navigace teda bude po té silnici tertiary navigovat normálne( a area bude ignorována. Pochopil jsem to dobr(e? Cus, ano, pochopils to dobre. A jak se pak r(es(í ne(jaká pojmenovaná plocha (náme(stí), pr(es které prochází ne(jaká silnice? Pokud nebude náme(stí se silnicí propojeno, tak jej navigace nikdy nenajde (nemá se tam jak dostat) Kdyz( se podívám do wiki: http://wiki.openstreetmap.org/wiki/Key:area / / /Pedestrian areas (for example squares and piazzas) should be formed using an closed-way around the perimeter and be tagged with //highway http://wiki.openstreetmap.org/wiki/Key:highway=pedestrian http://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian//and also //*area*=yes//. / /Where a road crosses a pedestrian area then a linear way tagged in the usual way should be overlaid across the square. This linear way should shares nodes with the pedestrian area at its entrance and exit from the square. / /In the context of roads, area=yes indicates that an area has no street lines within it (i.e., there is no given direction on the area). / /*Note:*//There is currently no clear agreement on how highway tag values other than pedestrian should be treated when also tagged with area=yes. / /*Note:*//Most pedestrian routing algorithms do not currently route correctly across area features, tending to route around the edge./ // Takz(e mi vychází, z(e náme(stí má mít s protínající cestou spolec(né body na vstupu a výstupu a u ostatních se jes(te( (rade(ji?) nedohodli. Jinak co jsem zkous(el navigace, ta ty me( kolem dokola neposílaly, poslaly me( úplne( jinudy. Marián Díky, Dalibor *From:*jzvc [mailto:j...@tpfree.net] *Sent:* Sunday, June 02, 2013 9:57 PM *To:* OpenStreetMap Czech Republic *Subject:* Re: [Talk-cz] Prosba o kontrolu navsi Pokud je treba z nejakyho duvodu udelat vyasfaltovanou plochu ... tak stim OSM moc nepocita... v kazdym pripade je ale naprosto nezbytny udelat cesty a nejaky bod, kde je krizovatka. Jinak navigace (zadna) nebude fungovat. A viz vejs, v tomhle pripade rozhodne NIKDY nespojovat to, co ma area s normalni cestou. Nektery navigace klido budou navigovat pres area. Takz(e mám nechat JOSM a KeepRight r(vát? A co to znamená, z(e budou navigovat pr(es area? Z(e jako pu*jdou naokolo místo rovne(? Ano presne jak pises - na varovani kasli, a navigace ti bude navigovat dokola. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] JOSM : satisfecit
salut et merci ;-) je te rejoins complètement. tu peux faire un résumé de ton expérience sur le wiki sur page josm ou dans mail en réponse et je reprendrai sur le wiki. c comme tu préfères. Cyrille37 Le 2 juin 2013 12:16, christian Herbé che...@free.fr a écrit : Bonjour Faisant du SIG non professionnel, j'ai été confronté au problème de modification des shapefiles, faute d'outil adapté. Encore aujourd'hui, si l'on fait une recherche sur internet, on ne trouve rien de satisfaisant dans les gratuits et les demandes sont nombreuses. QGIS est bien trop rigide dans ce domaine. Pourtant, l'outil existe bel et bien et il s'appelle JOSM. Avec lui, c'est un jeu d'enfant pour modifier un shapefile. Ca méritait d'être écrit, me semble -t- il ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag de Cyberbases/Espaces Publics Numériques
merci. À noter tout de même que dans un cybercafé on peut y boire un café mais pas dans les cyberbase/epn/... Le 4 juin 2013 18:49, Philippe Verdy verd...@wanadoo.fr a écrit : operator=* doit normalement désigner l'entité publique ou privée qui est responsable d'un site (au plan légal et comptable), autrement dit le commanditaire. C'est un nom d'organisation et non une classification générique du type de lieu. Je verrais plutôt service:type=FR:espace_public_numérique (sans abréviation epn obscure, et me^me avec des accents puisque c'est une nomenclature franco-française). A moins qu'il y ait une nomenclature européenne ou internationale pour ces espaces internet publics du genre: service:type=cybercafe operator=* (nom de l'opérateur public) operator:type=public/commercial/community (optionnel : le dernier pour les espaces de type associatif, privé mais largement ouvert à ses membres ou pour certaines missions, et pouvant avoir des subventions publiques) La notion de cybercafé est généralement commerciale, mais on a de plus en plus confusion avec les autres médias numériques (convergence oblige), et je ne vois pas trop l'intérêt de distinguer les cybercafés et les espaces multimédia alors que de plus en plus souvent ce sera le même support et qu'on trouvera aussi des services annexes (boissons, encas... souvent en distributeurs), et des services de télécommunication (téléphoner à un employeur...), et du conseil et des services spécialisés (formations en ligne, assistance, dépannage de matériel, réglage de logiciels, impression, studio de montage photo/vidéo ou graphique, échange de services comme le webdesign...) Le 4 juin 2013 18:02, Cyrille Giquello cyrill...@gmail.com a écrit : salut ça pourrait être bien d'ajouter un tags pour préciser, du genre operator=epn ou operator=cyberbase . operator ne doit pas être la bonne clé ... Le 31 mai 2013 19:28, Brice Mallet brice.mal...@free.fr a écrit : Bonjour, le terme le plus générique, en France, est espaces publics numériques qui regroupent les Cyberbases, cybercentres et autres espaces multimédia. J'en ai référencé un à Machecoul 44 : Nœud : Cybercentre (1978638217) Attributs : internet_access=service name=Cybercentre Noeud : car une salle seulement au sein du bâtiment médiathèque, avec entrée séparée A mon avis service est préférable à terminal car if you want to mention that there is personnel which helps you in case of problems http://wiki.openstreetmap.org/**wiki/Key:internet_accesshttp://wiki.openstreetmap.org/wiki/Key:internet_access ce qui est le propre des espaces publics numériques dans lequel un animateur est théoriquement toujours présent (pour accompagner en accès libre ou ateliers). Britz (les Cyberbases, ce fut mon activité que d'accompagner les communes à les mettre en place) Le 31/05/13 17:01, Emmanuel Lesouef a écrit : Bonjour, Avez-vous déjà renseigné ce que certains appellent des Cyberbases, d'autres des espaces publics numériques ? Si oui, comment ? Perso, je serais tenté par un tag sur la bâtiment : building=yes internet_access=terminal Merci de votre aide. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag de Cyberbases/Espaces Publics Numériques
Ah bon? Ceux que j'ai vu avaient toujours au moins un distributeur. Ceux qui n'en ont pas sont plutôt dans les médiathèques pour protéger aussi les livres, question de propreté parait-il, et pourtant on n'entre pas en enlevant ses chaussures à l'entrée et les sacs ou vêtements qui viennent de l'extérieur sont aussi salissants. De fait les cybercafés ou médiathèques ont de moins en moins souvent de matériel à disposition : on vient avec le sien, le lieu fournit une connexion Wifi, parfois une prise Ethernet. Ce sont des lieux soit pour travailler au calme quand on est trop loin de chez soi, ou pour du travail en réunion. Mpeme au travail on ne partage plus les ordinateurs, chacun le sien et chacun s'occupe de le nettoyer. Le 5 juin 2013 11:31, Cyrille Giquello cyrill...@gmail.com a écrit : merci. À noter tout de même que dans un cybercafé on peut y boire un café mais pas dans les cyberbase/epn/... Le 4 juin 2013 18:49, Philippe Verdy verd...@wanadoo.fr a écrit : operator=* doit normalement désigner l'entité publique ou privée qui est responsable d'un site (au plan légal et comptable), autrement dit le commanditaire. C'est un nom d'organisation et non une classification générique du type de lieu. Je verrais plutôt service:type=FR:espace_public_numérique (sans abréviation epn obscure, et me^me avec des accents puisque c'est une nomenclature franco-française). A moins qu'il y ait une nomenclature européenne ou internationale pour ces espaces internet publics du genre: service:type=cybercafe operator=* (nom de l'opérateur public) operator:type=public/commercial/community (optionnel : le dernier pour les espaces de type associatif, privé mais largement ouvert à ses membres ou pour certaines missions, et pouvant avoir des subventions publiques) La notion de cybercafé est généralement commerciale, mais on a de plus en plus confusion avec les autres médias numériques (convergence oblige), et je ne vois pas trop l'intérêt de distinguer les cybercafés et les espaces multimédia alors que de plus en plus souvent ce sera le même support et qu'on trouvera aussi des services annexes (boissons, encas... souvent en distributeurs), et des services de télécommunication (téléphoner à un employeur...), et du conseil et des services spécialisés (formations en ligne, assistance, dépannage de matériel, réglage de logiciels, impression, studio de montage photo/vidéo ou graphique, échange de services comme le webdesign...) Le 4 juin 2013 18:02, Cyrille Giquello cyrill...@gmail.com a écrit : salut ça pourrait être bien d'ajouter un tags pour préciser, du genre operator=epn ou operator=cyberbase . operator ne doit pas être la bonne clé ... Le 31 mai 2013 19:28, Brice Mallet brice.mal...@free.fr a écrit : Bonjour, le terme le plus générique, en France, est espaces publics numériques qui regroupent les Cyberbases, cybercentres et autres espaces multimédia. J'en ai référencé un à Machecoul 44 : Nœud : Cybercentre (1978638217) Attributs : internet_access=service name=Cybercentre Noeud : car une salle seulement au sein du bâtiment médiathèque, avec entrée séparée A mon avis service est préférable à terminal car if you want to mention that there is personnel which helps you in case of problems http://wiki.openstreetmap.org/**wiki/Key:internet_accesshttp://wiki.openstreetmap.org/wiki/Key:internet_access ce qui est le propre des espaces publics numériques dans lequel un animateur est théoriquement toujours présent (pour accompagner en accès libre ou ateliers). Britz (les Cyberbases, ce fut mon activité que d'accompagner les communes à les mettre en place) Le 31/05/13 17:01, Emmanuel Lesouef a écrit : Bonjour, Avez-vous déjà renseigné ce que certains appellent des Cyberbases, d'autres des espaces publics numériques ? Si oui, comment ? Perso, je serais tenté par un tag sur la bâtiment : building=yes internet_access=terminal Merci de votre aide. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Trottoirs à Montrouge
Si tu ajoute des way supportant les trottoir seulement, au way supportant la chaussée et le trottoir - via le tag sidewalk=both par exemple - tu te retrouve avec deux objet trottoirs!!! Comment fait le taggeur complet? il tag forcément les trottoir deux fois? il tag ce qui l'arrnage? celui qui ignore les trottoir indépendant risque de se retrouver avec des trottoir en moins si le contributeur de la zone n'a pas taggé a la fois le trottoir sur la chaussée principale ET a coté?! J'ai beaucoup de mal a comprendre ce qu'apporte cette représentation de donnée doublon par rapport a la solution actuelle dans le cas ou le trottoir est collé directement a coté de la voie. A part des complications immenses. On Le 5 juin 2013 01:36, Frédéric Bonifas fredericboni...@gmail.com a écrit : Je comprends ce point de vue mais il y a plusieurs façons possibles de représenter les données. Pour coller au schéma que tu décris, rien n'empêche de faire comme si les trottoirs n'existent pas : il suffit de les ignorer lors de l'utilisation des données OSM. L'ajout des trottoirs ne modifie a priori pas les données déjà présentes. Et le way sera alors assimilé à la chaussée complète. L'atomisation dont tu parles est déjà très présente dans la base, comme tu le cites avec les chaussées à voies séparées. Mais c'est aux outils exploitant les données OSM de le faire intelligemment. Par exemple, les trottoirs étant présents dans la relation associatedStreet, il est possible pour un outil d'autoriser la traversée depuis un trottoir jusqu'au trottoir d'en face à n'importe quel endroit de la route. Le 5 juin 2013 01:10, Tetsuo Shima tets...@gmail.com a écrit : Le way qui supporte la route est assimilé à la chaussée complète. C'est la raison pour laquelle il n'y a qu'un way alors que la route à souvent plus d'une voie. De la même manière les zone de stationnement sur la chaussée sont supportées par le way de la route ... Et donc aussi les trottoirs. Cette vision de la chaussée complète permet de transcrire la réalité physiques. Il est en effet possible de passer du trottoir à la voie n'importe ou le long de celle ci y compris de traverser d'un trottoir à l'autre. Avec l'atomisation des way on perd la circulation naturelle entre les différentes zone de la chaussée. C'est déjà un souci avec les chaussées à voie séparés pour lequel il est pas du tout évident de savoir si la traversée à pieds est possible ou pas. À priori les piétons on le droit d'emprunter la route aussi... Pas seulement au passage piéton. Le mardi 4 juin 2013, Frédéric Bonifas a écrit : ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Frédéric Bonifas +33672652807 skype:fredericbonifas ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Trottoirs à Montrouge
a déjà du mal avec les piéton qui peuvent ou pas traverser des surfaces accceder de la voie a l'aire dessiné a coté etc. pourquoi compliquer encore les choses en séparant le trottoir de la voie alors que physiquement il ne le sont pas! Le 5 juin 2013 14:03, Tetsuo Shima tets...@gmail.com a écrit : Si tu ajoute des way supportant les trottoir seulement, au way supportant la chaussée et le trottoir - via le tag sidewalk=both par exemple - tu te retrouve avec deux objet trottoirs!!! Comment fait le taggeur complet? il tag forcément les trottoir deux fois? il tag ce qui l'arrnage? celui qui ignore les trottoir indépendant risque de se retrouver avec des trottoir en moins si le contributeur de la zone n'a pas taggé a la fois le trottoir sur la chaussée principale ET a coté?! J'ai beaucoup de mal a comprendre ce qu'apporte cette représentation de donnée doublon par rapport a la solution actuelle dans le cas ou le trottoir est collé directement a coté de la voie. A part des complications immenses. On Le 5 juin 2013 01:36, Frédéric Bonifas fredericboni...@gmail.com a écrit : Je comprends ce point de vue mais il y a plusieurs façons possibles de représenter les données. Pour coller au schéma que tu décris, rien n'empêche de faire comme si les trottoirs n'existent pas : il suffit de les ignorer lors de l'utilisation des données OSM. L'ajout des trottoirs ne modifie a priori pas les données déjà présentes. Et le way sera alors assimilé à la chaussée complète. L'atomisation dont tu parles est déjà très présente dans la base, comme tu le cites avec les chaussées à voies séparées. Mais c'est aux outils exploitant les données OSM de le faire intelligemment. Par exemple, les trottoirs étant présents dans la relation associatedStreet, il est possible pour un outil d'autoriser la traversée depuis un trottoir jusqu'au trottoir d'en face à n'importe quel endroit de la route. Le 5 juin 2013 01:10, Tetsuo Shima tets...@gmail.com a écrit : Le way qui supporte la route est assimilé à la chaussée complète. C'est la raison pour laquelle il n'y a qu'un way alors que la route à souvent plus d'une voie. De la même manière les zone de stationnement sur la chaussée sont supportées par le way de la route ... Et donc aussi les trottoirs. Cette vision de la chaussée complète permet de transcrire la réalité physiques. Il est en effet possible de passer du trottoir à la voie n'importe ou le long de celle ci y compris de traverser d'un trottoir à l'autre. Avec l'atomisation des way on perd la circulation naturelle entre les différentes zone de la chaussée. C'est déjà un souci avec les chaussées à voie séparés pour lequel il est pas du tout évident de savoir si la traversée à pieds est possible ou pas. À priori les piétons on le droit d'emprunter la route aussi... Pas seulement au passage piéton. Le mardi 4 juin 2013, Frédéric Bonifas a écrit : ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Frédéric Bonifas +33672652807 skype:fredericbonifas ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Trottoirs à Montrouge
Je suis d'accord sur le principe: une route tracée en fialire a implicitement une largeur (qu'on peut estime par le nombde de voies et de directions et de la présence de tags indiquant des contre-allées, du stationnement (et de toute façon on a aussi le tracé des batiments et des murs ou clorures devant eux, et même assez souvent des arbres et bandes de pelouses éventuelles. Donc toutes les rues/routes tracées en fialire sont étendues avec un buffer, le but étant de convertir toujours le filaire en surface (même pour le rendu). De fait il n'y a pas séparation des rues et des trottoirs sauf si celle-ci est matérialisée par quelquechose tracé entre les deux. Il n'y a donc pas de raison de séparer les trottoirs de la chaussée, sauf si on raison voie par voie (mais alors il faudra passer non pas au filaire (qui ne fait que mentionner les directions, mais à un travcé des contours de surface de chaque voie (ce qui nécessiate encore un filaire, simplifié toutefois, pour marquer la direction prise normalement dans ce polygone. La question n'est donc pas s'il faut un tracé filaire ou surfacique polygonal, puisque le fialire orienté reste nécessaire La question est plutôt : en plus du fialire, est-ce utile d'ajouter (et non pas remplacer !) le tcontour surfacique? A mon avis non dans la plupart des cas où une largeur de buffer suffit pour convertir le filaire en surface, tout en véhiculant la direction que le surfacique ne sait pas mentionner. Puisque le filaire et son buffer (précisé dans un tag, ou estimé) sont donc nécessaires. autant utiliser cefait pour les trottoirs. Le 5 juin 2013 14:04, Tetsuo Shima tets...@gmail.com a écrit : a déjà du mal avec les piéton qui peuvent ou pas traverser des surfaces accceder de la voie a l'aire dessiné a coté etc. pourquoi compliquer encore les choses en séparant le trottoir de la voie alors que physiquement il ne le sont pas! Le 5 juin 2013 14:03, Tetsuo Shima tets...@gmail.com a écrit : Si tu ajoute des way supportant les trottoir seulement, au way supportant la chaussée et le trottoir - via le tag sidewalk=both par exemple - tu te retrouve avec deux objet trottoirs!!! Comment fait le taggeur complet? il tag forcément les trottoir deux fois? il tag ce qui l'arrnage? celui qui ignore les trottoir indépendant risque de se retrouver avec des trottoir en moins si le contributeur de la zone n'a pas taggé a la fois le trottoir sur la chaussée principale ET a coté?! J'ai beaucoup de mal a comprendre ce qu'apporte cette représentation de donnée doublon par rapport a la solution actuelle dans le cas ou le trottoir est collé directement a coté de la voie. A part des complications immenses. On Le 5 juin 2013 01:36, Frédéric Bonifas fredericboni...@gmail.com a écrit : Je comprends ce point de vue mais il y a plusieurs façons possibles de représenter les données. Pour coller au schéma que tu décris, rien n'empêche de faire comme si les trottoirs n'existent pas : il suffit de les ignorer lors de l'utilisation des données OSM. L'ajout des trottoirs ne modifie a priori pas les données déjà présentes. Et le way sera alors assimilé à la chaussée complète. L'atomisation dont tu parles est déjà très présente dans la base, comme tu le cites avec les chaussées à voies séparées. Mais c'est aux outils exploitant les données OSM de le faire intelligemment. Par exemple, les trottoirs étant présents dans la relation associatedStreet, il est possible pour un outil d'autoriser la traversée depuis un trottoir jusqu'au trottoir d'en face à n'importe quel endroit de la route. Le 5 juin 2013 01:10, Tetsuo Shima tets...@gmail.com a écrit : Le way qui supporte la route est assimilé à la chaussée complète. C'est la raison pour laquelle il n'y a qu'un way alors que la route à souvent plus d'une voie. De la même manière les zone de stationnement sur la chaussée sont supportées par le way de la route ... Et donc aussi les trottoirs. Cette vision de la chaussée complète permet de transcrire la réalité physiques. Il est en effet possible de passer du trottoir à la voie n'importe ou le long de celle ci y compris de traverser d'un trottoir à l'autre. Avec l'atomisation des way on perd la circulation naturelle entre les différentes zone de la chaussée. C'est déjà un souci avec les chaussées à voie séparés pour lequel il est pas du tout évident de savoir si la traversée à pieds est possible ou pas. À priori les piétons on le droit d'emprunter la route aussi... Pas seulement au passage piéton. Le mardi 4 juin 2013, Frédéric Bonifas a écrit : ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Frédéric Bonifas +33672652807 skype:fredericbonifas ___ Talk-fr mailing list Talk-fr@openstreetmap.org
Re: [OSM-talk-fr] Trottoirs à Montrouge
Le 5 juin 2013 14:04, Tetsuo Shima tets...@gmail.com a écrit : a déjà du mal avec les piéton qui peuvent ou pas traverser des surfaces accceder de la voie a l'aire dessiné a coté etc. pourquoi compliquer encore les choses en séparant le trottoir de la voie alors que physiquement il ne le sont pas! Les représentations du wiki ne sont à ma connaissance pas des obligations, mais des propositions. Si le trottoir suit le même chemin que la route, que route et trottoirs sont continus, et qu'il n'y a pas de séparation physique entre les deux, alors il n'y a pas de raison de séparer le trottoir de la route. Mais si le trottoir ne suit pas le même chemin que la route, ou que route ou trottoirs ont des discontinuités, ou qu'il y a une séparation physique entre les deux, alors il peut devenir intéressant d'utiliser deux descriptions séparées pour l'un et pour l'autre. Cordialement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag de Cyberbases/Espaces Publics Numériques
Le Tue, 4 Jun 2013 18:48:42 +0200, Philippe Verdy verd...@wanadoo.fr a écrit : operator=* doit normalement désigner l'entité publique ou privée qui est responsable d'un site (au plan légal et comptable), autrement dit le commanditaire. C'est un nom d'organisation et non une classification générique du type de lieu. Je verrais plutôt service:type=FR:espace_public_numérique (sans abréviation epn obscure, et me^me avec des accents puisque c'est une nomenclature franco-française). A moins qu'il y ait une nomenclature européenne ou internationale pour ces espaces internet publics du genre: service:type=cybercafe operator=* (nom de l'opérateur public) operator:type=public/commercial/community (optionnel : le dernier pour les espaces de type associatif, privé mais largement ouvert à ses membres ou pour certaines missions, et pouvant avoir des subventions publiques) La notion de cybercafé est généralement commerciale, mais on a de plus en plus confusion avec les autres médias numériques (convergence oblige), et je ne vois pas trop l'intérêt de distinguer les cybercafés et les espaces multimédia alors que de plus en plus souvent ce sera le même support et qu'on trouvera aussi des services annexes (boissons, encas... souvent en distributeurs), et des services de télécommunication (téléphoner à un employeur...), et du conseil et des services spécialisés (formations en ligne, assistance, dépannage de matériel, réglage de logiciels, impression, studio de montage photo/vidéo ou graphique, échange de services comme le webdesign...) Ok donc si je résume : * soit les tags sur un nœud dans le cas d'une pièce au sein d'un bâtiment, soit sur un polygone dans le cas d'un bâtiment complet. * utilisation des tags suivants : operator=Conseil Régional de Basse-Normandie (pour ce qui me concerne) service:type=FR:espace_public_numérique Du coup, je doute de la pertinence d'un tag aussi compliqué (pour moi) que service:type=FR:... Mais je manque sûrement de culture OSM sur les tags de ce type. Par contre la remarque concernant les services associés (télé-formation, etc.) méritent qu'on s'y attarde. -- Emmanuel Lesouef signature.asc Description: PGP signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Trottoirs à Montrouge
C'est exactement la même problématique que pour les pistes cyclables, qui ne soulèvent aucune opposition : les pistes cyclables sont très souvent cartographiées par des ways séparés alors qu'elles sont collées directement à côté de la voirie. Sur le wiki http://wiki.openstreetmap.org/wiki/Bicycle voir par exemple le cas T1 : la solution recommandée est de mettre les pistes cyclables comme séparées de la voirie. Pourquoi le trottoir qui est encore plus loin devrait lui être sur la voirie ? D'autre part, encore sur ce cas T1, un vélo peut très bien repasser sur la route principale à n'importe quel moment (cf photo). Peu de contestation sur ce schéma pourtant (qui me plait bien aussi). Et encore une fois, au risque de me répéter, pas de problème pour ignorer les trottoirs si on ne veut pas les utiliser ! Ca ne modifie pas les données existantes d'ajouter les trottoirs. Le 5 juin 2013 14:03, Tetsuo Shima tets...@gmail.com a écrit : Si tu ajoute des way supportant les trottoir seulement, au way supportant la chaussée et le trottoir - via le tag sidewalk=both par exemple - tu te retrouve avec deux objet trottoirs!!! Comment fait le taggeur complet? il tag forcément les trottoir deux fois? il tag ce qui l'arrnage? celui qui ignore les trottoir indépendant risque de se retrouver avec des trottoir en moins si le contributeur de la zone n'a pas taggé a la fois le trottoir sur la chaussée principale ET a coté?! J'ai beaucoup de mal a comprendre ce qu'apporte cette représentation de donnée doublon par rapport a la solution actuelle dans le cas ou le trottoir est collé directement a coté de la voie. A part des complications immenses. On Le 5 juin 2013 01:36, Frédéric Bonifas fredericboni...@gmail.com a écrit : Je comprends ce point de vue mais il y a plusieurs façons possibles de représenter les données. Pour coller au schéma que tu décris, rien n'empêche de faire comme si les trottoirs n'existent pas : il suffit de les ignorer lors de l'utilisation des données OSM. L'ajout des trottoirs ne modifie a priori pas les données déjà présentes. Et le way sera alors assimilé à la chaussée complète. L'atomisation dont tu parles est déjà très présente dans la base, comme tu le cites avec les chaussées à voies séparées. Mais c'est aux outils exploitant les données OSM de le faire intelligemment. Par exemple, les trottoirs étant présents dans la relation associatedStreet, il est possible pour un outil d'autoriser la traversée depuis un trottoir jusqu'au trottoir d'en face à n'importe quel endroit de la route. Le 5 juin 2013 01:10, Tetsuo Shima tets...@gmail.com a écrit : Le way qui supporte la route est assimilé à la chaussée complète. C'est la raison pour laquelle il n'y a qu'un way alors que la route à souvent plus d'une voie. De la même manière les zone de stationnement sur la chaussée sont supportées par le way de la route ... Et donc aussi les trottoirs. Cette vision de la chaussée complète permet de transcrire la réalité physiques. Il est en effet possible de passer du trottoir à la voie n'importe ou le long de celle ci y compris de traverser d'un trottoir à l'autre. Avec l'atomisation des way on perd la circulation naturelle entre les différentes zone de la chaussée. C'est déjà un souci avec les chaussées à voie séparés pour lequel il est pas du tout évident de savoir si la traversée à pieds est possible ou pas. À priori les piétons on le droit d'emprunter la route aussi... Pas seulement au passage piéton. Le mardi 4 juin 2013, Frédéric Bonifas a écrit : ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Frédéric Bonifas +33672652807 skype:fredericbonifas ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Frédéric Bonifas +33672652807 skype:fredericbonifas ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Trottoirs à Montrouge
Je suis un peu étonné par cette interprétation du cas T1. La photo et le schéma montrent bien que la voie est séparée de la route, et donc séparation physique = tracés séparés eux aussi. J'ai toujours considéré que justement les tracés séparés étaient fait lorsqu'il y avait une séparation physique, et que lorsqu'il n'y en avait pas, on avait un seul way et des tags descriptifs. C'est vrai que plus on va dans le détail, plus on risque de passer à des ways séparés pour renseigner une foule de détails et affiner aussi la géométrie. Ca sera sûrement indispensable à terme pour le micromapping lié à l'accessibilité pour bien prendre en compte les problèmes de cheminement. Pour les trottoirs, je pense que comme pour les pistes cyclables on a des cas très différents et que si on devait les mettre dans un tableau on aurait un truc à peu près aussi long que celui sur les pistes cyclables. Lorsque les trottoirs suivent le tracé de la rue (cas majoritaire dans les rues résidentielles), un seul way me semble suffisant avec des tags sidewalk pour les décrire. Le 5 juin 2013 15:12, Frédéric Bonifas fredericboni...@gmail.com a écrit : C'est exactement la même problématique que pour les pistes cyclables, qui ne soulèvent aucune opposition : les pistes cyclables sont très souvent cartographiées par des ways séparés alors qu'elles sont collées directement à côté de la voirie. Sur le wiki http://wiki.openstreetmap.org/wiki/Bicycle voir par exemple le cas T1 : la solution recommandée est de mettre les pistes cyclables comme séparées de la voirie. Pourquoi le trottoir qui est encore plus loin devrait lui être sur la voirie ? D'autre part, encore sur ce cas T1, un vélo peut très bien repasser sur la route principale à n'importe quel moment (cf photo). Peu de contestation sur ce schéma pourtant (qui me plait bien aussi). Et encore une fois, au risque de me répéter, pas de problème pour ignorer les trottoirs si on ne veut pas les utiliser ! Ca ne modifie pas les données existantes d'ajouter les trottoirs. Le 5 juin 2013 14:03, Tetsuo Shima tets...@gmail.com a écrit : Si tu ajoute des way supportant les trottoir seulement, au way supportant la chaussée et le trottoir - via le tag sidewalk=both par exemple - tu te retrouve avec deux objet trottoirs!!! Comment fait le taggeur complet? il tag forcément les trottoir deux fois? il tag ce qui l'arrnage? celui qui ignore les trottoir indépendant risque de se retrouver avec des trottoir en moins si le contributeur de la zone n'a pas taggé a la fois le trottoir sur la chaussée principale ET a coté?! J'ai beaucoup de mal a comprendre ce qu'apporte cette représentation de donnée doublon par rapport a la solution actuelle dans le cas ou le trottoir est collé directement a coté de la voie. A part des complications immenses. On Le 5 juin 2013 01:36, Frédéric Bonifas fredericboni...@gmail.com a écrit : Je comprends ce point de vue mais il y a plusieurs façons possibles de représenter les données. Pour coller au schéma que tu décris, rien n'empêche de faire comme si les trottoirs n'existent pas : il suffit de les ignorer lors de l'utilisation des données OSM. L'ajout des trottoirs ne modifie a priori pas les données déjà présentes. Et le way sera alors assimilé à la chaussée complète. L'atomisation dont tu parles est déjà très présente dans la base, comme tu le cites avec les chaussées à voies séparées. Mais c'est aux outils exploitant les données OSM de le faire intelligemment. Par exemple, les trottoirs étant présents dans la relation associatedStreet, il est possible pour un outil d'autoriser la traversée depuis un trottoir jusqu'au trottoir d'en face à n'importe quel endroit de la route. Le 5 juin 2013 01:10, Tetsuo Shima tets...@gmail.com a écrit : Le way qui supporte la route est assimilé à la chaussée complète. C'est la raison pour laquelle il n'y a qu'un way alors que la route à souvent plus d'une voie. De la même manière les zone de stationnement sur la chaussée sont supportées par le way de la route ... Et donc aussi les trottoirs. Cette vision de la chaussée complète permet de transcrire la réalité physiques. Il est en effet possible de passer du trottoir à la voie n'importe ou le long de celle ci y compris de traverser d'un trottoir à l'autre. Avec l'atomisation des way on perd la circulation naturelle entre les différentes zone de la chaussée. C'est déjà un souci avec les chaussées à voie séparés pour lequel il est pas du tout évident de savoir si la traversée à pieds est possible ou pas. À priori les piétons on le droit d'emprunter la route aussi... Pas seulement au passage piéton. Le mardi 4 juin 2013, Frédéric Bonifas a écrit : ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Frédéric Bonifas +33672652807 skype:fredericbonifas ___ Talk-fr mailing list
Re: [OSM-talk-fr] Trottoirs à Montrouge
Le 5 juin 2013 16:16, Christian Quest cqu...@openstreetmap.fr a écrit : Je suis un peu étonné par cette interprétation du cas T1. La photo et le schéma montrent bien que la voie est séparée de la route, et donc séparation physique = tracés séparés eux aussi. D'accord avec ça pour tracés séparés. Mais alors : * si la piste cyclable est séparée de la route * si le trottoir est collé à la piste cyclable Et bien le trottoir est également séparé de la voie, au même titre que la piste cyclable. J'ai toujours considéré que justement les tracés séparés étaient fait lorsqu'il y avait une séparation physique, et que lorsqu'il n'y en avait pas, on avait un seul way et des tags descriptifs. Séparation physique ça dépend pour quel mode de transport : actuellement par exemple, les entrées/sorties de rond-point sont cartographiées comme deux ways séparés car il y a un terre-plein central - c'est bien une séparation physique pour une voiture, mais pas pour un piéton. C'est vrai que plus on va dans le détail, plus on risque de passer à des ways séparés pour renseigner une foule de détails et affiner aussi la géométrie. Ca sera sûrement indispensable à terme pour le micromapping lié à l'accessibilité pour bien prendre en compte les problèmes de cheminement. Je suis du même avis. C'est rigolo ce débat sur les trottoirs car c'est le même qu'il y a 7 ans quand j'avais proposé les tags cycleway=* :) http://lists.openstreetmap.org/pipermail/talk/2006-July/005697.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Trottoirs à Montrouge
Bonjour, Am 04.06.2013 21:14, schrieb Frédéric Bonifas: cela surcharge la plupart des rendus Là c'est un problème des rendus. Ignorer les ways ayant le tag footway=pedestrian est possible pour ne pas surcharger. Simplement ignorer les footway=pedestrian ne résout pas le problème. Il faut au moins distinguer entre un footway qui est parallèle à un highway=* et si proche de celui-ci qu'on peut supposer que c'est un trottoir et tout autre footway. Je ne dis pas que ce n'est pas faisable, ton calculateur d'itinéraire doit bien le faire, mais un footway=sideway rendrait la tâche plus facile. Rainer ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Réunion contributeur Ardèchois
Bonjour, Réunion des contributeurs ardéchois et des personnes interressés par le projet : le mercredi 12 juin 2013 de 18h à 20h à la salle de réunion des Inforoutes, ZI du Lac, InnoParc à Privas 07. liste de diffusion spécifique à notre département : inscrivez vous sur http://listes.openstreetmap.fr/wws/subscribe/local-ardeche Détails sur http://wiki.openstreetmap.org/wiki/Mappeurs_Ardechois Contact : Henry-Pascal ELDIN, el...@inforoutes.fr , 06 84 11 70 35 04 75 30 79 15 http://www.openstreetmap.org/?lat=44.717213lon=4.609967zoom=18layers=M -- Cordialement, Henry-Pascal ELDIN Courayon, Route de St Bauzile 07210 CHOMERAC, FRANCE Tel 04 75 65 19 93 Orange 06 80 75 74 80 http://www.eldin.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Édition wiki
Salut, Je ne comprends pas trop l'édition wiki :-( Cf. L'entrée Guyane française - Suriname ici : http://wiki.openstreetmap.org/wiki/FR:OSM_Map_On_Garmin/Download#Amerique_du_Sud Comment se fait-il que dans la colonne Auteur il y ait un chiffre ? J'ai pourtant pris modèle sur le reste ! @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Édition wiki
Bonjour Le 05/06/2013 19:55, Stéphane MARTIN a écrit : Comment se fait-il que dans la colonne Auteur il y ait un chiffre ? J'ai pourtant pris modèle sur le reste ! Un lien non wiki (entre crochet unique) sans texte alternatif produit un lien internet affichant un chiffre sinon il affiche le texte alternatif [http://foo] = [1] [http://foo plop] = plop Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Mobile Monday / matinées thématiques de Silicon Sentier le 24 juin...
En complément des Mobile Monday , Silicon Sentier organise des matinées thématiques dédiées à des problématiques métier rencontrées par les acteurs de la mobilité. Chaque rencontre est conçue aider à trouver des réponses et/ou pistes de résolutions aux interrogations techniques ou d’usages qui peuvent bloquer. Est-ce que 2 ou 3 animateurs OSM seraient dispo/intéressés à organiser une matinée dédiée aux croisements entre les usages smartphones et OSM. Voici le format : 9h00 : Accueil café 9h15-10h00 : Etat de l’art. Les tendances, le marché, les outils et les bonnes pratiques. 10h00 : Lancement des workshops en parallèle /// Workshop #1 (2h / 15 pers max) : axe à définir par l'animateur. /// Workshop #2 (2h / 15 pers max) : axe à définir par l'animateur. 12h00 : Fin de la matinée Qui pour m'accompagner le 24 juin ? -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] imports des bâtiments ronds convertis du cadastre raster
Le 04/06/2013 18:39, Ab_fab a écrit : Mais c'est un pousse-au-TOC ce truc ! Plus sérieusement, quelle démarche suivre pour tirer profit de l'analyse (usage de l'API osmose ?) pour _ récupérer l'id des objets _ les charger (overpass API ?) _ les classer par nombre de noeuds les constituant En ajoutant l'argument class=1 on a que les ronds L'API d'osmose est là : http://wiki.openstreetmap.org/wiki/FR:Osmose/api/0.2 Tu peux avoir les données par région : http://osmose.openstreetmap.fr/fr/api/0.2/errors?item=7011class=1limit=500country=france_aquitainefull=true L'API supporte une limite à 500 max Tu peux aussi remplacer france_centre par france* Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] micromapping : ascenseurs !!!
Un nouveau venu en micromapping : l'ascenseur http://tile.openstreetmap.fr/?zoom=20lat=44.13742lon=4.80729layers=B0F En attente : - la rampe - les accès (entrée+sortie) - Cordialement, ZIMMY Jean-Louis ZIMMERMANN Développeur territorial (ville d'Orange,FR84) Mandataire OSM-France sur le Grand-Sud-est -- View this message in context: http://gis.19327.n5.nabble.com/micromapping-ascenseurs-tp5764134.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Trottoirs à Montrouge
Bonjour, Je partage aussi cet avis. Je trouve que la meilleure représentation pour les trottoirs serait d'utiliser des surfaces. En attendant je tague sidewalk=* sur la route plutôt que de faire un chemin parallèle séparé. Par contre, s'il y a une séparation physique (du point de vue du piéton) entre la route et le trottoir, j'aurais tendance à créer un chemin séparé (même règle que pour les highway). Olivier (User:oligo) Le 05/06/2013 14:39, Ista Pouss a écrit : Le 5 juin 2013 14:04, Tetsuo Shima tets...@gmail.com mailto:tets...@gmail.com a écrit : a déjà du mal avec les piéton qui peuvent ou pas traverser des surfaces accceder de la voie a l'aire dessiné a coté etc. pourquoi compliquer encore les choses en séparant le trottoir de la voie alors que physiquement il ne le sont pas! Les représentations du wiki ne sont à ma connaissance pas des obligations, mais des propositions. Si le trottoir suit le même chemin que la route, que route et trottoirs sont continus, et qu'il n'y a pas de séparation physique entre les deux, alors il n'y a pas de raison de séparer le trottoir de la route. Mais si le trottoir ne suit pas le même chemin que la route, ou que route ou trottoirs ont des discontinuités, ou qu'il y a une séparation physique entre les deux, alors il peut devenir intéressant d'utiliser deux descriptions séparées pour l'un et pour l'autre. Cordialement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag de Cyberbases/Espaces Publics Numériques
A mon avis, si l'on veut absolument être précis, il faudrait renseigner les tags ainsi : operator = commune en général les EPN sont gérés par la commune (propriétaire des lieux, employeur de l'animateur présent, ...), une délégation à une association peut aussi se rencontrer. Si l'on veut renseigner Conseil Régional de Basse-Normandie ou Cyber-base, il serait préférable d'utiliser franchise = ... (http://wiki.openstreetmap.org/wiki/Key:franchise) Le Conseil Régional de Basse-Normandie peut verser une subvention sur projet, organise des évènements, anime le réseau, ... (http://epn.region-basse-normandie.fr/), c'est plus proche de la notion de franchise Britz Le 05/06/13 14:59, Emmanuel Lesouef a écrit : Le Tue, 4 Jun 2013 18:48:42 +0200, Philippe Verdy verd...@wanadoo.fr a écrit : operator=* doit normalement désigner l'entité publique ou privée qui est responsable d'un site (au plan légal et comptable), autrement dit le commanditaire. C'est un nom d'organisation et non une classification générique du type de lieu. (...) Ok donc si je résume : * soit les tags sur un nœud dans le cas d'une pièce au sein d'un bâtiment, soit sur un polygone dans le cas d'un bâtiment complet. * utilisation des tags suivants : operator=Conseil Régional de Basse-Normandie (pour ce qui me concerne) service:type=FR:espace_public_numérique Du coup, je doute de la pertinence d'un tag aussi compliqué (pour moi) que service:type=FR:... Mais je manque sûrement de culture OSM sur les tags de ce type. Par contre la remarque concernant les services associés (télé-formation, etc.) méritent qu'on s'y attarde. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag de Cyberbases/Espaces Publics Numériques
Le 5 juin 2013 14:59, Emmanuel Lesouef eleso...@lorinand.org a écrit : Ok donc si je résume : * soit les tags sur un nœud dans le cas d'une pièce au sein d'un bâtiment, soit sur un polygone dans le cas d'un bâtiment complet. * utilisation des tags suivants : operator=Conseil Régional de Basse-Normandie (pour ce qui me concerne) service:type=FR:espace_public_numérique Du coup, je doute de la pertinence d'un tag aussi compliqué (pour moi) que service:type=FR:... Mais je manque sûrement de culture OSM sur les tags de ce type. Par contre la remarque concernant les services associés (télé-formation, etc.) méritent qu'on s'y attarde. Reste plus qu'à documenter tout ça dans le wiki pour aider les prochains qui se poseront cette même question... Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] imports des bâtiments ronds convertis du cadastre raster
Merci Frédéric, Il me manquait ce genre d'exemple sur la page du wiki de l'API pour que j'arrive à construire convenablement une requête hier Le 5 juin 2013 21:44, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Le 04/06/2013 18:39, Ab_fab a écrit : Mais c'est un pousse-au-TOC ce truc ! Plus sérieusement, quelle démarche suivre pour tirer profit de l'analyse (usage de l'API osmose ?) pour _ récupérer l'id des objets _ les charger (overpass API ?) _ les classer par nombre de noeuds les constituant En ajoutant l'argument class=1 on a que les ronds L'API d'osmose est là : http://wiki.openstreetmap.org/**wiki/FR:Osmose/api/0.2http://wiki.openstreetmap.org/wiki/FR:Osmose/api/0.2 Tu peux avoir les données par région : http://osmose.openstreetmap.**fr/fr/api/0.2/errors?item=** 7011class=1limit=500**country=france_aquitainefull=**truehttp://osmose.openstreetmap.fr/fr/api/0.2/errors?item=7011class=1limit=500country=france_aquitainefull=true L'API supporte une limite à 500 max Tu peux aussi remplacer france_centre par france* Frédéric. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] micromapping : ascenseurs !!!
Comment faut-il les tagguer our qu'ils apparaissent ? Je connais un highway=elevator qui n'est pas rendu : http://tile.openstreetmap.fr/?zoom=20lat=43.59663lon=1.4232layers=B0F (le point d’entrée du metro à coté de l'excalier), le node 1341975752. http://www.openstreetmap.org/browse/node/1341975752 Art. Le 5 juin 2013 21:43, ZIMMY jeanlouis.zimmerm...@laposte.net a écrit : Un nouveau venu en micromapping : l'ascenseur http://tile.openstreetmap.fr/?zoom=20lat=44.13742lon=4.80729layers=B0F En attente : - la rampe - les accès (entrée+sortie) - Cordialement, ZIMMY Jean-Louis ZIMMERMANN Développeur territorial (ville d'Orange,FR84) Mandataire OSM-France sur le Grand-Sud-est -- View this message in context: http://gis.19327.n5.nabble.com/micromapping-ascenseurs-tp5764134.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] micromapping : ascenseurs !!!
Bonsoir, Le 05/06/2013 22:44, Art Penteur a écrit : Comment faut-il les tagguer our qu'ils apparaissent ? Je connais un highway=elevator qui n'est pas rendu : http://tile.openstreetmap.fr/?zoom=20lat=43.59663lon=1.4232layers=B0F (le point d’entrée du metro à coté de l'excalier), le node 1341975752. http://www.openstreetmap.org/browse/node/1341975752 Il faut croire que subway_entrance prend le dessus, car ce point : http://www.openstreetmap.org/browse/node/1403259601 avec juste highway=elevator est rendu : http://tile.openstreetmap.fr/?zoom=20lat=48.8281lon=2.2326layers=B0F vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Véloroute Charle le téméraire
Bonjour du coté de Metz aujourd'hui, j'ai placé quelque info manquantes du coté de Ars sur Moselle. Je pense qu'il y a une erreur sur la partie de la véloroute charles le téméraire passant par la. sur OSM, la relation contient l'objet 24835009. or sur le terrain, il y a un panneau indiquant la véloroute sur l'objet 214795507 qui est un chemin goudronnée je ne l' ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Véloroute Charle le téméraire
mauvaise manip, le message est parti tout seul Je disait donc que je ne l'ai pas suivi. Peut-être des contributeurs locaux pourrons il corriger cordialement Claude Le 05/06/2013, claude maraniclaude.mar...@gmail.com a écrit : Bonjour du coté de Metz aujourd'hui, j'ai placé quelque info manquantes du coté de Ars sur Moselle. Je pense qu'il y a une erreur sur la partie de la véloroute charles le téméraire passant par la. sur OSM, la relation contient l'objet 24835009. or sur le terrain, il y a un panneau indiquant la véloroute sur l'objet 214795507 qui est un chemin goudronnée je ne l' ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
