date:20160609

Hallo,
Bilden wir den jetzt die Realität ab, oder das, was grad beliebt? Der Kurs 
fährt, es ist nicht nur ein Konzessionserhalter der einmal im Jahr fährt (wobei 
ich die am liebsten auch gleich in die Karte eintragen würde), und OSM ist 
keine kommerzielle Karte. 
Zum VOR-Plan: Der 236er fährt an Schultagen auch nur 2 Mal bis Strebersdorf, 
ist aber strichliert eingezeichnet, und in Langenzersdorf, wo er auch seine 
verschiedenen Routenvarianten auch so ein bis 2 Mal nur an Schultagen fährt ist 
er auch eingezeichnet. Also hier reicht es offenbar, wenn ein Streckenteil 2 
Mal befahren wird... So gesehen ist auch hier schon was recht dünn befahrenes 
eingezeichnet. Auch die 220er Schulkurse sind eingezeichnet., ok, das sind (auf 
verschiedenen Routen) 1 und 3 Fahrten. Aber auch ähnlich spärlich. ZUgegebener 
maßen werden einzelne Fahrten (wie zb. 31A über Doningasse) nicht 
eingezeichnet. Aber dennoch entsprechen diese Fahrten der REalität. Da wird mir 
immer wieder gesagt, wir bilden die Realität ab (erst wieder kürzlich bezüglich 
TEDi ("ground truth"), und dann macht man im ÖV, weil es grad bequem ist ein 
Pick-and-choose, nur weil irgendwann der Wartungsaufwand hoch wird (was ich 
nicht wirklich denke, für mich sind ordentlich erstellte ÖV-Relationen ziemlich 
einfach wartbar). Der Kurs fährt einen Großteil des Jahres, wir mappen NICHT 
für den Render (auch das wurde mir oft genug gesagt) und eigentlich sollten 
diese beiden Sachen (Wahrheit abbilden, nicht für eine "Karte" im klassischen 
Sinn mappen) schon reichen, um jede "Einziehfahrt" mit Fahrgastbetrieb und 
jeden existenten Kurs, der an genug Tagen fährt einzuzeichnen. Der 20B fährt 
einen Großteil des Jahres nicht, ist aber auf der VOR und WL-Karte drauf
Mit freundlichen GrüßenRobinD
PS: Am VOR Plan ist der eine Kurs vom 79B über Aspernallee, Schule auch 
eingezeichnet, obwohl da ja "eh auch der 77A fährt". Also so ist das auch 
nicht, dass man, nur weil es ein einzelner Schulkurs ist, wo naoch was anderes 
fährt dann was weglässt. Insofern ist das weglassen der "Einziehfahrt" vom 95A 
wohl eher ein Fehler als wirklich gewollt...
  ___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

[talk-ph] Cagas Bridge under construction (Nabua,CamSur)

2016-06-09 Diskussionsfäden Ervin Malicdem

Cagas bridge is under construction and is only passable by light vehicles.
Reroute to Iriga for large vehicles.

Please revert this changeset once the construction is completed.

http://www.openstreetmap.org/changeset/39921140

Ervin M.
*Schadow1 Expeditions* - A Filipino must not be a stranger to his own
motherland.
http://www.s1expeditions.com
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [OSM-talk] iD news: v1.9.6 released

2016-06-09 Diskussionsfäden Minh Nguyen

Martin Koppenhoefer  gmail.com> writes:

> 
> 
> sent from a phone
> 
> > Il giorno 09 giu 2016, alle ore 02:23, Minh Nguyen 
nguyen.cincinnati.oh.us> ha scritto:
> > 
> > If I understand correctly, you’re referring to a situation where, for
> > instance, Wikipedia editors have opted to discuss both an “administrative
> > territorial entity” and its government in the same article, whereas Wikidata
> > editors have decided to separate the concepts into two different items
> 
> at least the former is very common for cities I believe (didn't conduct a
scientific study about it though),
> I'm not so sure how common the latter is, my impression when I last looked
was that many of the socio
> geographic entities are still missing in wikidata (so rather than using 2
distinct objects there is one
> which corresponds to a part of the article), their editors seem to have a
preference for political
> administrative entities.

I’m not sure whether we’re talking about the same concepts, so here are some
data points about the kinds of Wikidata items that iD might end up
associating with place POIs or boundary relations (among the many kinds of
features that can be tagged with `wikipedia` and `wikidata`):

* Currently, Wikidata has 1,775,365 items tagged as “human settlements”. [1]
You’d expect to see these items tagged on place POIs, including cities and
villages but also places that don’t have boundaries (like unincorporated
places).

* “Administrative territorial entity” is the superset of “human
settlements”. This superset has 2,225,880 items. [2] You’d see these items
on place POIs and boundary=administrative boundary relations.

* “Human-geographic territorial entity” is the superset of “administrative
territorial entity” that also includes cultural and purely political
boundaries. That superset is less than 1% larger (2,245,631). [3] Something
that’s a human-geographic territorial entity but not an administrative
territorial entity probably shouldn’t be mapped in OSM in the first place.

Rather than searching Wikidata, iD essentially only follows the explicit
link from the user-specified Wikipedia article to its Wikidata item. The
presence of this link indicates that Wikipedians currently consider the item
to be synonymous. To get a better sense of how widespread these iD-generated
tags would be, the queries above could be filtered to those items that have
sitelinks. Unfortunately, that particular query times out on the Wikidata
Query Service. (It’s a great service, but like overpass turbo, it has its
limits.)

> > Wikipedia tends to be proactive about creating separate articles when
> > there’s a notable distinction between the various meanings of a name, but
> > Wikidata follows suit almost as a rule. So there is a 1:1 correspondence
> > between the various meanings of China on the English Wikipedia and the
> > various Wikidata items for those meanings. `wikipedia=en:China` maps to
> > , which is for the People's Republic. If
> > the mapper had a different definition of China in mind, both the `wikipedia`
> > and `wikidata` tags would reflect that.
> 
> clearly the china article in wp/en has a much broader scope than the
linked Wikidata item people's republic
> of china. The latter starts looking at things from 1949, Wikipedia "China"
some thousand years earlier.

The Wikipedia article provides historical context, including historical
borders, as any encyclopedia article on this topic should. By contrast, the
Wikidata item is more focused on the present, much the way an OSM boundary
relation should reflect the present. (The historical boundaries go in
OpenHistoricalMap, after all.) Both Wikipedia and Wikidata have entries for
other definitions of China. [4] To me, this suggests that the Wikidata item
more naturally fits an OSM feature than the Wikipedia article does.

[1] http://tinyurl.com/h9p4qb7
[2] http://tinyurl.com/zvrft74
[3] http://tinyurl.com/zuzcvly
[4] https://en.wikipedia.org/wiki/China_(disambiguation) and the Wikidata
items linked to the articles linked from that page

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

[Talk-it] Stampare una mappa uMap

2016-06-09 Diskussionsfäden EugPez

Ho creato la seguente mappa come test

http://umap.openstreetmap.fr/it/map/new/#17/45.52911/9.58812
  

Vorrei salvarla possibilmente in PDF per poi stamparla in grande formato
(90x60) su un plotter, così come è possibile creare un file PDF dall'editor
ID di OSM.

Io ho provato a cercare in wiki OSM on paper, ma non sono riuscito a trovare
nulla.

Ho provato a importare il file Geojson da uMap, perdendo le icone (vabbè),
ma il plugin per la stampa continua ad andare in errore.

Come potrei fare?

Grazie
Ciao




--
View this message in context: 
http://gis.19327.n5.nabble.com/Stampare-una-mappa-uMap-tp5875135.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-at] Schulkurse und ähnliche Gelegenheitskurse von Linienbuslinien

2016-06-09 Diskussionsfäden Kevin Kofler

Christian Aigner wrote:
> Meine Eltern wohnen in einem Dorf, wo der Bus nur dreimal am Tag kommt.
> Morgens, mittags und abends. Trotzdem ist es richtig, daß die Buslinie
> eingezeichnet ist.

Es ist aber nicht dasselbe, ob es diese Buslinie grundsätzlich nur dreimal 
am Tag gibt, oder ob das eine von der Stammstrecke einer wesentlich 
höherfrequenten Buslinie abweichende Einzelfahrt ist (die außerdem noch 
exakt auf der Strecke einer anderen Buslinie fährt, also, daß da Busse 
fahren, war ohnehin ersichtlich).

Auf dem proprietären kommerziellen Stadtplan, von dem ich ein gedrucktes 
Exemplar besitze, ist auf dem 96A-Streckenabschnitt natürlich kein 95A 
eingezeichnet. Auf den offiziellen Plänen von VOR:
https://www.vor.at/fileadmin/CONTENT/Downloads/Plaene/Gesamtnetz_Wien.pdf
und Wiener Linien:
http://www.wienerlinien.at/eportal3/ep/downloadTracker.do/path/media/files/2016/gesamtnetzplan_wien_176236.pdf?oid=82853=pdf
auch nicht. (Disclaimer: Diese Pläne verlinke ich nur zum Vergleich, ein 
Abzeichnen in die OSM ist aus lizenzrechtlichen Gründen NICHT zulässig.) Ich 
denke, kein einziges kommerzielles Planunternehmen würde auf die Idee 
kommen, da "95A" hinzuschreiben.

Liebe Grüße,
Kevin

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

Re: [Talk-de] TEDi - Stores richtiger Name

2016-06-09 Diskussionsfäden Hakuch

Es ist die Frage, ab wann sowas wichtig wird zu mappen. Das war, wie ich
mich jetzt wieder erinnere, auch der Punkt wo ich aus der Diskussion ein
wenig ausgestiegen bin: Was macht eigentlich Sinn in der OSM Datenbank
zu landen? Das hab ich mich bei dieser Unternehmensketten Sache sehr
stark gefragt als dann einige mit den rechtlichen Firmenkonstrukten der
einzelnen Unternehmen argumentiert haben. Ich find es äußerst unsinnig
das im Geobereich zu diskutieren und jedes Objekt dann redundant zu
mappen, viel lieber würd ich eine Lösung im Wikidata sehen auf die mand
ann verlinken kann. Eigentlich könnte das auch für die namen gelten als
Default, und wenns bei nem Objekt nicht dem Default entspricht dann
wirds halt dort überschrieben..

On 09.06.2016 22:47, Jan Engelhardt wrote:
> 
> On Thursday 2016-06-09 18:01, Hakuch wrote:
>>
>> Daraus ist dann die Idee entstanden, eine einheitliche Liste im Wiki zu
>> bauen.
>> http://forum.openstreetmap.org/viewtopic.php?id=53553
>>
>> Leider ist das ganze dann über Detailfragen eingeschlafen, vor allem wie
>> man mit brand/operator umgeht und wie sinnvoll die überhaupt sind.
> 
> Bei Tankstellen wird das interessant. Es gibt nämlich welche, die sehen
> untereinander gleich aus (z.B. bft), beziehen aber wohl unterschiedliche
> Kraftstoffmarken (sofern man das bei Noname überhaupt sagen kann).
> Und es gibt welche, die verkaufen ARAL-Kraftstoff, sind aber nun gar nicht
> blau angemalt.
> 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-fr] Osmose vs ref:FR:LaPoste

2016-06-09 Diskussionsfäden Francois Gouget


Bon j'ai crée une page française pour post_box afin d'éviter que 
d'autres ne se fassent avoir avec cette historire de ref vs. 
ref:FR:LaPoste.

https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dpost_box

Je n'ai pas de photo de boîte aux lettres française donc si vous en 
avez vous pouvez remplacer la photo USPS.

J'ai ajouté un paragraphe décrivant les spécificités de la situation 
française et enlevé ceux des US et de l'Angleterre. Je considère que 
dupliquer les infos spécifiques à chaque pays dans chaque traduction 
n'est pas une bonne utilisation des ressources et n'a aucune chance de 
rester à jour.

A vous de jouer pour compléter / corriger la page.


-- 
Francois Gouget   http://fgouget.free.fr/
   Vote Electronique: Les gens qui votent ne décident rien.
 Ceux qui comptent les votes décident de tout.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] TEDi - Stores richtiger Name

2016-06-09 Diskussionsfäden Jan Engelhardt

On Thursday 2016-06-09 18:01, Hakuch wrote:
>
>Daraus ist dann die Idee entstanden, eine einheitliche Liste im Wiki zu
>bauen.
>http://forum.openstreetmap.org/viewtopic.php?id=53553
>
>Leider ist das ganze dann über Detailfragen eingeschlafen, vor allem wie
>man mit brand/operator umgeht und wie sinnvoll die überhaupt sind.

Bei Tankstellen wird das interessant. Es gibt nämlich welche, die sehen
untereinander gleich aus (z.B. bft), beziehen aber wohl unterschiedliche
Kraftstoffmarken (sofern man das bei Noname überhaupt sagen kann).
Und es gibt welche, die verkaufen ARAL-Kraftstoff, sind aber nun gar nicht
blau angemalt.

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

Re: [Talk-de] Verwendung von Markenlogos in Karten?

2016-06-09 Diskussionsfäden Sven Geggus

nebulon42  wrote:

>> Das soll wohl eine Flasche oder Pillendose darstellen.
> Hast du richtig erkannt, kapiert also doch jemand.

Nachdem ich mir das in groß angesehen habe und überlgt habe, was das sein
könnte. Spontan erkennen ist etwas anderes.

Da das grüne Kreuz auch in Deutschland häufiger wird hab ich jetzt erst mal
das reingetan.

Sven

-- 
Das allgemeine Persönlichkeitsrecht (Art. 2 Abs.1 i.V.m. Art.1 Abs. 1GG)
umfasst das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität
informationstechnischer Systeme. (BVerfG, 1BvR 370/07)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-it] Buongiorno, sono un nuovo iscritto

2016-06-09 Diskussionsfäden scratera

...efettivamente qualcosa di strano c'è...se si fa calcolare percorsi brevi
all'ora l'autorouting funzionamentre se si fa calcolare distanze lunghe va
in palla...



--
View this message in context: 
http://gis.19327.n5.nabble.com/Buongiorno-sono-un-nuovo-iscritto-tp5874921p5875125.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-de] Verwendung von Markenlogos in Karten?

2016-06-09 Diskussionsfäden nebulon42

Am 2016-06-09 um 12:25 schrieb Sven Geggus:
> Das derzeitige carto-css Apothekensymbol kapiert kein Mensch.
Das sehe ich - wenig überraschend - nicht so. :)

> Das soll wohl eine Flasche oder Pillendose darstellen.
Hast du richtig erkannt, kapiert also doch jemand.

nebulon42



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

Re: [Talk-GB] RFC: Semi Automatic Import of schools

2016-06-09 Diskussionsfäden Christian Ledermann

OK I rolled out the new version, can you take another look?

Thanks again for your detailed and helpful comments.

On 9 June 2016 at 15:40, Robert Whittaker (OSM lists)
 wrote:
> On 9 June 2016 at 10:50, Christian Ledermann
>  wrote:
>> I'd like to propose to use http://schools.mapthe.uk for a semi automatic 
>> import
>> of Ordonance Survey Open School grounds data combined with
>> edubase and seed data into OpenStreetMap.
>>
>> The Tool is available at http://schools.mapthe.uk/
>> The sourcecode and documentation is available at
>> https://github.com/cleder/os-opendata-edubase
>>
>> My tests with this tool are very encouraging, I'd like to go forward
>> to the imports mailing list with this proposal.
>
> I have a quick look at your tool, but I'm afraid the instances I was
> presented with initially left me rather confused about exactly what it
> is doing and where the data is coming from. (I didn't read the github
> readme to start with, as that looked from the start to be instructions
> for installing the app yourself, rather than how to use it.) I think
> that basic info should be provided on the page itself so users don't
> have to go elsewhere to find  out what is what. It would also be good
> to have a better description of how things are selected / matched up
> between the datasets. In particular, is the tool trying to go through
> all school polygons in OS Open Map, or just those matched to an
> Edubase entry that doesn't have an existing ref:edubase match in OSM?
> Are you just matching / showing things based on proximity to the
> current OS Open Map polygon?
>
> The first few things I was shown were as follows:
>
> * http://schools.mapthe.uk/assign/22701/ -- The blue polygon seems to
> be for a churchyard, not a school. Why/how was is chosen / matched? Is
> it an error in OS Open Map perhaps?
>
> * http://schools.mapthe.uk/assign/22591/ -- There's a school name but
> no other data shown. Is this because there are no nearby edubase
> entries? (It would be helpful if the page says so.) This might not
> mean the site is not/no longer a school though, as it could be a
> satellite site for a school with a main address elsewhere.
>
> * http://schools.mapthe.uk/assign/5733/ -- The red area is an existing
> OSM polygon, but this isn't made clear on the page. Also could the
> full set of tags be shown in the section at the bottom, ideally as a
> table?
>
> A few other comments / suggestions:
>
> * It would also be helpful if you could explicitly list the source
> data items their key data explicitly on your page view (as you already
> partially do with the OSM data) and also provide clickable links to
> the OSM object (e.g. http://www.openstreetmap.org/way/148997325) and
> full Edubase entry (e.g.
> http://www.education.gov.uk/edubase/establishment/summary.xhtml?urn=111777)
> to allow people to inspect them.
>
> * In the case where you think an OSM object already exists, could
> there be a button to add/replace the existing tags with the data you
> think is appropriate (ideally with an option to overwrite or preserve
> each existing tag that clashes)? Any maybe an option to completely
> replace/update the geometry too -- though this is a bit dangerous, as
> you'd have to be careful with what to do with the original nodes in
> case they were also being used for other things.
>
> * I don't think "os-open" is a suitable source tag if it's supposed to
> be referring to OS Open Map Local. Using something approximating the
> full name would be better as it is less ambiguous. "os-open" could be
> mistaken for a general tag referring to any of the OS OpenData
> products.
>
> * The tags to be added would be easier to read if they were presented
> as separate rows in a table.
>
> * Could the map layer switcher be shown open all the time? Before
> adding a polygon, one should really check the Satellite view, so this
> would save a click each time.
>
> * The height of the map view is annoying small on my large monitor.
>
> * Are you looking for OSM nodes and relations as well as ways? (e.g.
> at http://schools.mapthe.uk/assign/26893/ there's an existing node
> that doesn't seem to be detected.)
>
> * When there's no OSM data, the forwards and backwards links look like
> they're in a box with a title "Openstreetmap Data", when they're
> actually nothing to do with any OSM data. If there's no OSM data to
> display, then you should either have some placeholder text to say so,
> or omit the heading.
>
> * The telephone numbers (phone=*) aren't in the international format
> specified at http://wiki.openstreetmap.org/wiki/Key:phone .
>
> Finally, from the few polygons I've looked at, they're not always that
> accurate. In more than 50% of cases, I think I would want to do better
> drawing it manually over the satellite imagery. I'm not convinced that
> providing a tool that encourages / makes it easy for people to add
> lower quality data is necessarily a

Re: [OSM-talk] iD news: v1.9.6 released

2016-06-09 Diskussionsfäden Martin Koppenhoefer



sent from a phone

> Il giorno 09 giu 2016, alle ore 02:23, Minh Nguyen 
>  ha scritto:
> 
> If I understand correctly, you’re referring to a situation where, for
> instance, Wikipedia editors have opted to discuss both an “administrative
> territorial entity” and its government in the same article, whereas Wikidata
> editors have decided to separate the concepts into two different items



at least the former is very common for cities I believe (didn't conduct a 
scientific study about it though), I'm not so sure how common the latter is, my 
impression when I last looked was that many of the socio geographic entities 
are still missing in wikidata (so rather than using 2 distinct objects there is 
one which corresponds to a part of the article), their editors seem to have a 
preference for political administrative entities.


> 
> Wikipedia tends to be proactive about creating separate articles when
> there’s a notable distinction between the various meanings of a name, but
> Wikidata follows suit almost as a rule. So there is a 1:1 correspondence
> between the various meanings of China on the English Wikipedia and the
> various Wikidata items for those meanings. `wikipedia=en:China` maps to
> , which is for the People's Republic. If
> the mapper had a different definition of China in mind, both the `wikipedia`
> and `wikidata` tags would reflect that.


clearly the china article in wp/en has a much broader scope than the linked 
Wikidata item people's republic of china. The latter starts looking at things 
from 1949, Wikipedia "China" some thousand years earlier.


cheers,
Martin 


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

Re: [Talk-de] TEDi - Stores richtiger Name


Bitte beruhige dich ein bisschen. Es wurden 2 Lösungen vorgestellt wovon
eine seit längerem produktiv eingesetzt wird. Wenn es um eine neue
Ladenkette geht oder die aus irgendwelchen Gründen die noch nicht
erfasst ist, ein Ticket eröffnen mit den nütigen Details und gut ist.

Natürlich gibt es in OSM gewisse Unschärfen, so ist meistens das was wir
als Name erfassen eigenlich der Brand und andere kleine Probleme, aber
es ist nicht so, dass andere Kartendatenanbieter nicht die gleichen
Probleme haben, und glaube ja nicht das die Läden selber es genau wissen.

Simon


Am 09.06.2016 um 18:39 schrieb DC Viennablog:
> Also muss ich wohl damit leben, dass OSM ein riesiger Clusterfuck ist, wo
> jeder was reinschreibt wie er grad will, aber alle Versuche es etwas
> sinnvoller zu vereinheitlichen einfach im Sand verlaufen und abgeblockt
> werden?
>
> Na gut, dann bleib ich schön
> brav beim Mappen von Buslinien im Raum Wien (da haben wir eh grad auf
> Talk-at eine Diskussion über Schulkurse), und versuche erst gar nicht,
> irgendwas anderes zu "verbessern".
>
> Wenn hier nicht irgendwelche
> großen Durchbrüche oder Heureka-Momente zu dem Namensthema kommen, melde
> ich mich von der Liste in 24 Stunden wieder ab...
>
> Noch viel Spaß beim weiteren mappen
> emergency99 (RobinD) aus Wien.
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de




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

Re: [OSM-talk-fr] Crédit licence données OdbL avec fond de carte Gmaps

2016-06-09 Diskussionsfäden Philippe Verdy

Goolgle ne peut pas s'approprier les données qui ne sont pas hébergées sur
son serveur. Il ne le fait que si on charge les POI OSM sur son appli, mais
avec un simple OpenLayers, les superpositions sont indépendantes, les URLs
ne sont pas sur les mêmes domaines, la liaison ne se fait que sur le poste
client, un navigateur web dont l'utilsiation n'appartient pas à Google
(même si c'est un Google Chrome, ça peut être n'importe quel navigateur,
IE, Edge, Safari, Firefox ou autre navigateur mobile).

Il suffit d'utiliser un framework OpenLayers pour charger des couches
séparées sans rien demander aux serveur Google pour les POI d'OSM.
OpenLayers peut asusi bien afficher des couches du cadastre et Google ne se
les approprie pas, ce n'est pas lui qui les héberge. On peut aussi utiliser
un espace d'hébergement dédié à Google sur son cloud, mais cela reste une
espace privé pour celui qui l'utilise. Attention aux espaces gratuits de
son cloud qui n'ont pas les mêmes conditions d'utilisation (exemple
Blogspot, où Google dispose du droit de réutiliser le contenu à sa guise).

Sur un espace loué à Google sur son cloud, on a même le droit de refuser
les visites par son bot indexeur sur les pages qu'on souhaite, de la même
façon que pour un autre site indépendant. Google n'est plsu alors que le
prestataire technique d'hébergement, mais celui qui loue cet espace en fait
ce qu'il veut dans les limites permises par la loi d'une part et des
limites d'utilisation (débit total, charges IO/CPU/mémoire, limite de
stockage web ou base de données).

En revanche si on utilise directement l'API Google Maps pour intégrer des
données OSM, là oui ça pose problème, mais même si Google veut réutiliser
ces données, il ne pourrait le faire qu'en respectant nos licences et donc
avec mention des crédits nécessaires. Ses robots se garderont bien de faire
cette exportation et réutilisation, au risque de compromettre le jeu de
données de Google qui devrait être ouvert ensuite. OpenLayers est fait pour
ça; assurer la séparation technique sans rien avoir à charger sur un
serveur Google.

Si maintenant Google considère qu'OpenLayers lui donne ce droit, alors même
le site d'OSM est en danger d'appropriation par Google car OSM utilise
OpenLayers sur son propre site.

Il faut juste prendre garde au nom de domaine utilisé pour héberger les
données en question. La fusion se fera sur le poste client en requêtes
séparées.



Le 9 juin 2016 à 20:53, Christian Quest  a écrit :

> C'est un (gros) poil plus complexe que ça...
>
> Si tu lit les conditions d'utilisation des service de Google, ce dernier
> s'autorise le droit de réutiliser les données que tu affiche sur son fond
> via son API... et comme ceci ne se fera pas en respectant l'ODbL, en
> principe tu ne devrais pas mettre des données OSM sur un fond Google ;)
>
> Si tu le fait quand même, oui l'attribution est nécessaire.
>
>
>
> Le 9 juin 2016 à 16:58, Florian LAINEZ  a écrit :
>
>> Bonjour,
>> Je me demande si le crédit « © les contributeurs d’OpenStreetMap » doit
>> être apposé sur une carte affichant des POIs d'OSM avec un fond de carte
>> Gmaps.
>>
>> Je n'ai trouvé ce cas particulier ni dans le wiki ni sur la page
>> http://www.openstreetmap.org/copyright
>>
>> Merci pour vos réponses
>>
>> --
>>
>> *Florian Lainez*
>> @overflorian 
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] RFC: Semi Automatic Import of schools

2016-06-09 Diskussionsfäden Christian Ledermann

On 9 June 2016 at 15:40, Robert Whittaker (OSM lists)
 wrote:
> On 9 June 2016 at 10:50, Christian Ledermann
>  wrote:
>> I'd like to propose to use http://schools.mapthe.uk for a semi automatic 
>> import
>> of Ordonance Survey Open School grounds data combined with
>> edubase and seed data into OpenStreetMap.
>>
>> The Tool is available at http://schools.mapthe.uk/
>> The sourcecode and documentation is available at
>> https://github.com/cleder/os-opendata-edubase
>>
>> My tests with this tool are very encouraging, I'd like to go forward
>> to the imports mailing list with this proposal.
>
> I have a quick look at your tool, but I'm afraid the instances I was
> presented with initially left me rather confused about exactly what it
> is doing and where the data is coming from. (I didn't read the github
> readme to start with, as that looked from the start to be instructions
> for installing the app yourself, rather than how to use it.) I think
> that basic info should be provided on the page itself so users don't
> have to go elsewhere to find  out what is what. It would also be good
> to have a better description of how things are selected / matched up
> between the datasets. In particular, is the tool trying to go through
> all school polygons in OS Open Map, or just those matched to an
> Edubase entry that doesn't have an existing ref:edubase match in OSM?

All school polygons in OS Open Local

> Are you just matching / showing things based on proximity to the
> current OS Open Map polygon?

yes

>
> The first few things I was shown were as follows:
>
> * http://schools.mapthe.uk/assign/22701/ -- The blue polygon seems to
> be for a churchyard, not a school. Why/how was is chosen / matched? Is
> it an error in OS Open Map perhaps?

Yes this is an Error in OS Open

> * http://schools.mapthe.uk/assign/22591/ -- There's a school name but
> no other data shown. Is this because there are no nearby edubase
> entries?

Right.

>(It would be helpful if the page says so.) This might not
> mean the site is not/no longer a school though, as it could be a
> satellite site for a school with a main address elsewhere.

added ;-)

>
> * http://schools.mapthe.uk/assign/5733/ -- The red area is an existing
> OSM polygon, but this isn't made clear on the page. Also could the
> full set of tags be shown in the section at the bottom, ideally as a
> table?

I display other_tags + osm_id and name
the db tables look like this:


 Table "public.points"
Column| Type |
Modifiers
--+--+--
 ogc_fid  | integer  | not null default
nextval('points_ogc_fid_seq'::regclass)
 wkb_geometry | geometry(Point,4326) |
 osm_id   | character varying|
 name | character varying|
 barrier  | character varying|
 highway  | character varying|
 ref  | character varying|
 address  | character varying|
 is_in| character varying|
 place| character varying|
 man_made | character varying|
 other_tags   | hstore   |

Table "public.lines"
Column|   Type|
Modifiers
--+---+-
 ogc_fid  | integer   | not null default
nextval('lines_ogc_fid_seq'::regclass)
 wkb_geometry | geometry(LineString,4326) |
 osm_id   | character varying |
 name | character varying |
 highway  | character varying |
 waterway | character varying |
 aerialway| character varying |
 barrier  | character varying |
 man_made | character varying |
 other_tags   | hstore|

  Table "public.multilinestrings"
Column|  Type  |
  Modifiers
--++
 ogc_fid  | integer| not null default
nextval('multilinestrings_ogc_fid_seq'::regclass)
 wkb_geometry | geometry(MultiLineString,4326) |
 osm_id   | character varying  |
 name | character varying  |
 type | character varying  |
 other_tags   | hstore |


Table "public.multipolygons"
Column|Type |
  Modifiers
--+-+-
 ogc_fid  | integer | not null default
nextval('multipolygons_ogc_fid_seq'::regclass)
 wkb_geometry | geometry(MultiPolygon,4326) |
 osm_id   | character varying   |
 osm_way_id   |

Re: [Talk-it] utilizzo ford=yes su piccoli torrenti/ruscelli asciutti (o quasi)

2016-06-09 Diskussionsfäden Martin Koppenhoefer



sent from a phone

> Il giorno 09 giu 2016, alle ore 10:27, demon.box  ha 
> scritto:
> 
> in altre parole ford=yes và soltanto messo dove effettivamente "ci si bagna
> le scarpe"?



no, ford è un passaggio per attraversare un torrente senza ponte, se poi spesso 
quel torrente non porta acqua, non è un problema, perché quando l'acqua c'è si 
può attraversare lì 


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

Re: [OSM-legal-talk] FYI Collective Database Guideline


Am 09.06.2016 um 17:40 schrieb Christoph Hormann:
> On Thursday 09 June 2016, Simon Poole wrote:
>> I can understand the desire for a negative example, but:
>>
>> - this is documentation of use that we are happy with, not of the
>> opposite.
> But we are happy with uses that invoke share-alike as well, aren't we?

Basically the issue is that the guidelines are essentially "safe
harbour" statements, "we are ok if you do X", to provide a more secure
and stable environment for users of our data.

They do not claim to be the only possible interpretation of the ODbL and
they do not claim that use that is outside of the guidelines  is
automatically incompatible with the ODbL. We do however believe that the
guidelines can be reasonably assumed to be covered by the ODbL and
making these statements or clarifications if you so wish is within our
rights as licensor.

Giving non-trivial (aka concrete business use cases) negative examples
not only has the danger of essentially by fiat declaring something
"illegal" were no case has been made and that we've not been able to
look at in detail, it further relies on readers understanding the fine
difference between "not covered by the guideline" and "not covered by
the ODbL" outlined above. Determining the later is something that
ultimately would have to be decided by a court and I believe I can
safely say the OSMF does not want to tie its hands outside of the
context of the guidelines to when it can instantiate legal action and
when not.
>> - as the preamble says there may be other ODbL compliant ways that to
>> not invoke share-alike to combine datasets outside of those detailed
>> in the guideline.
>>
>> - using a contrived non-trivial negative example has the "it is
>> definitely going to happen" problem that it will be seen as a ruling
>> in use cases which are not on our table and of which we don't know
>> the details.
> I try to avoid getting again into a discussion on the guideline itself 
> here (i voiced my concerns previously - no need to do this again at 
> this point).  In any case it would be the first single sided guideline 
> that does not draw a line between two fields of data use.
>
> And as i read the text of the guideline it implies certain limits, for 
> example
>
> "non-OSM data completely replaces a particular type of geometry or data"
>
> implies the situation is different in some way if it does not completely 
> replace and
>
> "uses either all OSM data or no OSM data for that property"
>
> implies that a data mixture in properties changes the situation.
>
> In other words: having precisely formulated points in parameter space 
> but not having limits defined in relation to these points looks odd.
>
I already gave the de-duplication example as use that is not covered by
the guideline, which in turn is consistent with the already existing
guidelines, specifically the "Horizontal Layer Guideline".  I like to
call it "the all or nothing rule".  So yes the guideline says you are
only covered by it if you don't intermingle OSM data with 3rd party data
of the same type within an extract of suitable size.

Simon



signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-talk-fr] Crédit licence données OdbL avec fond de carte Gmaps

2016-06-09 Diskussionsfäden Christian Quest

C'est un (gros) poil plus complexe que ça...

Si tu lit les conditions d'utilisation des service de Google, ce dernier
s'autorise le droit de réutiliser les données que tu affiche sur son fond
via son API... et comme ceci ne se fera pas en respectant l'ODbL, en
principe tu ne devrais pas mettre des données OSM sur un fond Google ;)

Si tu le fait quand même, oui l'attribution est nécessaire.



Le 9 juin 2016 à 16:58, Florian LAINEZ  a écrit :

> Bonjour,
> Je me demande si le crédit « © les contributeurs d’OpenStreetMap » doit
> être apposé sur une carte affichant des POIs d'OSM avec un fond de carte
> Gmaps.
>
> Je n'ai trouvé ce cas particulier ni dans le wiki ni sur la page
> http://www.openstreetmap.org/copyright
>
> Merci pour vos réponses
>
> --
>
> *Florian Lainez*
> @overflorian 
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] Crédit licence données OdbL avec fond de carte Gmaps

2016-06-09 Diskussionsfäden Philippe Verdy

Tout à fait, OSM c'est d'abord les données avant même les fonds de carte
produits avec ces données.

Toute utilisation des données aux fins de les distribuer ou transmettre,
que ce soit pour produire un fond de carte ou pour toute utilisation
dérivée, même si on intègre aussi d'autres données, doivent être créditées.

Créditer OSM n'empêche pas de créditer aussi Google pour son fond de carte,
dans les conditions qu'il exige ou selon le contrat de service que vous
avez avec Google.

On a des exemples de crédits multiples, pas seulement pour les rendus.
Ainsi on peut créer des applis mixant diverses sources cartographiques (on
le fait sur le site OSM pour les fonds d'image aériennes de Bing par
exemple, Bing étant crédité pour ce fond orthophotographique en plus des
crédits propres à OSM pour les données qu'on gère). On le fait de la même
manière si une application affiche les feuilles cadastrales, et on crédite
le cadastre aussi dans les données importées dans OSM (cependant l'accord
avec le cadastre nous permet de le citer indirectement comme "les
contributeurs d'OSM", puisque le lien affiché mène sur une page donnant
explicitement crédit des données du cadastre français (et des autres
fournisseurs).

Ce lien doit être clair: si on ne veut pas surcharger une carte, le lien
doit afficher une mention claire de "Crédits" avec un lien *direct* (sans
avoir à chercher) vers une page stable et à jour donnant la liste des
crédits nécessaires.

Cette page doit être librement accessible par n'importe qui, sans
inscription préalable, autant que possible elle doit être statique, et en
tout cas elle ne doit nécessiter l'installation d'uacun logiciel spécifique
en dehors des fonctionnalités de base de n'importe quel navigateur web.
Elle doit être accessible même si on a bloqué les cookies ou scripts.

Le contenu doit être lisible clairement, et il est prudent de la concevoir
de la façon la plus simple possible (attention aux contenus "dynamiques"
dépendant du profil du visiteur, et uax publicités envahissantes: il ne
s'agit pas de voir d'abord une vidéo avant de pouvoir poursuivre et lire le
contenu qui ne doit faire l'objet d'aucune restriction pour sa consultation
: tout visiteur ayant accès à votre carte affichant des données OSM doit
avoir dans les mêmes conditions le libre accès aux infos de crédit
obligatoires).

Si ce n'est pas une page séparée, il est possible d'afficher une popup au
dessus de la page courante donnant le détail. Ceci est valable même en cas
d'utilisation de technologies non web (par exempel dans une appli écrite en
Flash ou dans une appli autonome hors navigateur). Si les données sont des
fichiers sans application, le jeux de données devrait incmure un fichier
README ou LICENCE ou similaire donnant la liste complète des crédits,
droits et obligations.

Cet accès doit être permanent tant que les données OSM installées ou
accessibles seront utilisables (pas seulement planqué dans un installateur
affichant une longue page de texte de CGU avant l'installation,
généralement une page que personne ne lit en entier ou qu'on oublie et
qu'on a du mal à retrouver plus tard au moment où seront présentées les
données OSM).






Le 9 juin 2016 à 17:30, Nicolas Dumoulin  a écrit :

> Le Thu, 9 Jun 2016 16:58:43 +0200,
> Florian LAINEZ  a écrit :
>
> > Bonjour,
> > Je me demande si le crédit « © les contributeurs d’OpenStreetMap »
> > doit être apposé sur une carte affichant des POIs d'OSM avec un fond
> > de carte Gmaps.
> >
> > Je n'ai trouvé ce cas particulier ni dans le wiki ni sur la page
> > http://www.openstreetmap.org/copyright
> >
> > Merci pour vos réponses
>
> Pour moi, c'est pourtant clair :
> "Vous êtes libre de copier, *distribuer*, *transmettre* et adapter nos
> données, à condition que vous créditiez, OpenStreetMap et ses
> contributeurs."
>
> Donc oui, OSM doit être crédité pour les POIs affichés.
>
> --
> Nicolas Dumoulin
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-br] Buildings no OpenStreetMap

2016-06-09 Diskussionsfäden Tarcisio Oliveira

Muito interessante essa forma de atribuir o numero da casa, a precisão 
do endereço se tornar muito maior

vou começar a fazer assim por aqui também.

Em 09-06-2016 09:36, santamariense escreveu:

Pessoal, se alguém tiver interesse em mapear numeração de casas, lojas
e afins, eu me disponho a adicionar (desenhar) as "buildings=yes", o
que vai facilitar a coleta de dados, além de já deixar com melhor
precisão.

Mas, tem que ir a campo recolher numeração. Resumindo, eu desenho as
buildings da sua área de interesse com a condição que no mínimo seja
adicionada a numeração e nome da rua à casa.

Se alguém tiver interesse, é só se pronunciar a qualquer momento. Bons
mapeamentos a todos.

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



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

Re: [Talk-de] TEDi - Stores richtiger Name

2016-06-09 Diskussionsfäden DC Viennablog

Also muss ich wohl damit leben, dass OSM ein riesiger Clusterfuck ist, wo
jeder was reinschreibt wie er grad will, aber alle Versuche es etwas
sinnvoller zu vereinheitlichen einfach im Sand verlaufen und abgeblockt
werden?

Na gut, dann bleib ich schön
brav beim Mappen von Buslinien im Raum Wien (da haben wir eh grad auf
Talk-at eine Diskussion über Schulkurse), und versuche erst gar nicht,
irgendwas anderes zu "verbessern".

Wenn hier nicht irgendwelche
großen Durchbrüche oder Heureka-Momente zu dem Namensthema kommen, melde
ich mich von der Liste in 24 Stunden wieder ab...

Noch viel Spaß beim weiteren mappen
emergency99 (RobinD) aus Wien.

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

Re: [Talk-de] TEDi - Stores richtiger Name

2016-06-09 Diskussionsfäden Hakuch

Ach jetz is der Thread von talk-at hier rüber gewandert, dabei hab ich
mich da extra angemeldet um meinen Senf dazu zu geben :)

Also diese Diskussion gab es auch schonmal im deutschen Forum in
ähnlicher Form, das ist dann darin gemündet, dass wir festgestellt
haben, dass das Problem sich nicht nur auf die Namen beschränkt.

Aber erst mal zu den Namen, mein letzter Standpunkt war dieser hier:
http://forum.openstreetmap.org/viewtopic.php?pid=569328#p569328

Also eine Unterscheidung zwischen Initialabkürzungen, silbenkurzwörtern,
allgemeine Abkürzungen, gebräuchliche Eigennamen Abkürzungen. Versalien
nur wenn höchstens 3.

Dann hatten wir das Problem mit den Edeka Märkten, dass die ja eine ganz
kreative unterschiedliche Namensgebung haben, aber eigentlich haben wir
bei allen möglichen ladenketten das Problem, dass kein einheitliche
Taggingschema vorhanden ist.

Daraus ist dann die Idee entstanden, eine einheitliche Liste im Wiki zu
bauen.
http://forum.openstreetmap.org/viewtopic.php?id=53553

Leider ist das ganze dann über Detailfragen eingeschlafen, vor allem wie
man mit brand/operator umgeht und wie sinnvoll die überhaupt sind. Aber
grundsätzlich fände ich das immer noch eine gute Sache um die
Taggingschemas zu vereinheitlichen.

On 09.06.2016 13:12, DC Viennablog wrote:
> Hallo allerseits,
> ich habe vor kurzem ein Geschäft der Linie "TEDi" in die OSM eingetragen. Da 
> laut LOGO, Website und eben auch vor Ort TEDi am Geschäft steht, heißt die 
> Geschäftslinie wohl so. Nach einer Overpass-turbo suche ergaben sich jedoch 
> etwa 80 "TEDi" und 210 "Tedi". Dennoch dachte ich, dass (da der Name ein 
> Akronym ist, das „TEDi“ geschrieben gehört) TEDi richtig ist, und besserte 
> das (ohne zu wissen, das sowas ein mechanischer Edit ist) österreich- und 
> deutschlandweit aus. Da aber nun (wohl insofern richtiger weise) der Edit von 
> Tedi auf TEDi wieder revertiert wurde, frage ich halt hier jetzt auch nach: 
> Wie soll jetzt das Geschäft gemappt werden?
> 
> Ich persönlich kann es nicht ausstehen, wenn man ein Datenbanksystem hat (und 
> die OSM ist nicht anderes) und da sind ein und das selbe Ding (hier Filialen 
> von TEDi) in verschiedenen Schreibweisen und mit oft unterschiedlichen shop 
> Tags drinnen… Die Filialen scheinen alle ident zu sein. Also alles 
> variety-stores mit dem Namen TEDi...
> 
> Im Sinne der Einheitlichkeit wäre hier die Findung einer Namenkonvention 
> (gerne auch in der OSM-WIKI dokumentiert) wünschenswert.
> 
> Gibt es vielleicht einen Fall zum Exempel bezüglich Firmenschreibweisen?
> 
> Hoffe hier weis wer Rat!
> 
> Mit freundlichen Grüßen
> RobinD. (emergency99)
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
> 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-cz] kct_neco=neco [was: Re: Cykloznačení - puntík se stříškou]

2016-06-09 Diskussionsfäden Marián Kyral

Ahoj,
moc pěkně jsi to popsal. Já jsem pro kaskádu. To vypadá použitelně.

Marián


-- Původní zpráva --
Od: Petr Vozdecký 
Komu: OpenStreetMap Czech Republic 
Datum: 9. 6. 2016 13:36:46
Předmět: Re: [Talk-cz] kct_neco=neco [was: Re: Cykloznačení - puntík se 
stříškou]

"

Ahoj vsem, ktere dane tema zajima (ostatni to preskocte, je to dlouhy... :o)

navrh zmeny tagovaciho schematu uverejneny v CZ Weekly 301 mel za ukol 
vyvolat diskusi (nelze se domnivat, ze je bez vad, dokonaly, 
vsepodchycujici...), coz se stalo jen okrajove. Soucasna debata ukazuje, ze 
existuji otazky, ktere si zaslouzi odpoved.

Prostor ve Weekly nebyl takovy, aby bylo mozne (vhodne) tam placat dlouhe 
texty, vysvetleni, priklady. Ano, bod 5 a 6 je tak kvuli tomu napsan tak 
"pravnicky", nemusi byt pochopitelny. Ostatne i jako jine pasaze textu.

Cili nyni zkusim napsat trochu vice.

Cilem bylo
1) ZCELA odstranit tag kct_barva=* Duvody jsou popsany, jsou zrejme. Cely 
navrh vychazi z toho, ze tento zamer a jeho zduvodneni (argumenty, cile) 
jsou nepopiratelne.
2) Narovnat logiku tagovani zachovanim (obnovenim) stromove (kaskadove) 
struktury
3) Vytvorit moznost tagovat vsechny kombinace (ne)znacenych tras, ktere se u
nas vyskytuji (protoze jsme svetovy extrem) a to jednak zachovanim plne 
kompatibility pro vnejsi svet (to dnes nemame), pripadne vytvorenim 
schematu, ktery lze od nas jako od zeme, ktera se s tim musela vyporadat 
ponekud obsirneji, prevzit

Co lze rozumet pod pojmem "stromova struktura". Neco jako:
objekt=zivocich
zivocich=savec
savec=pes
Ono by sice slo napsat objekt=pes, ale pokud z nejakeho duvodu chceme 
sledovat  i ty ostatni veliciny, musime je tak jako tak otagovat a prave 
stromova struktura nabizi pridanou hodnotu vyuziti kaskadoveho dedeni 
vlastnosti, sledovani jednoznacne nadrazenosti dane hodnoty (! a toto v 
nasem pripade predevsim) apod. A krom jiného - pokud je dobře navržena, pak 
tam, kde existuje příliš mnoho kombinací a sledovaných vlastností, popíše je
na minimu klíčů

Obdobne v OSM uzivame kaskadu treba zde:
landuse=construction
construction=farmland

Navrhovane schema rika (po jednotlivych vrstvach kaskady):
type=route
definujeme, ze relace (pripominam, ze tagujeme relaci) je nejaka trasa, tedy
linie, u znacenych (i neznacenych) tras bude pouzit VZDY tento tag, protoze 
vsechny trasy maji tuto vlastnost 

route=foot | hiking | bicycle | ski | horse | wheelchair
v tomto levelu kaskady definujeme trase vlastnosti, ktere je nejvice 
rozlisuji (maji nejvyssi vliv na dalsi uziti, nejvice rozdeluji cilove 
skupiny uzivatelu, maji vliv na vykresleni apod., napr. se vykresluji v 
zimnich/letnich mapach). Jsou to skupiny (zjednodušený český význam) 
"vycházková | turistická | cyklistická | lyžařská | koňská | vozíčkářská". 
Zde bych poznamenal, že v reálných podmínkách České republiky existuje 
specifický průnik mezi "hiking" a "bicycle" a tím jsou tzv. 
"cykloturistické" trasy KČT. Jsou to trasy vedené zpravidla lesem, značené 
směrníky typově shodnými jako turistické značení a terénní značky jsou 
podobně jako turistické "white+color:bar", ale fyzicky větší v podobě 
"yellow+color_bar". Tyto trasy nejsou v navrhovaném schematu zatím rozlišeny
a je skutečně vhodné k diskusi, zda a jak je rozlišit samostatným tagem v 
této úrovni kaskády, např. route=cycletourist - to proto, abychom opravdu 
jednoznačně odlišili "silniční" cykloturistiku (vedenou po cyklotrasách a 
cyklostezkách) od terénní cykloturistiky.

foot | hiking | bicycle | ski | horse | wheelchair=major | local | learning 
| ruin | peak | spring | interesting_object
v tomto levelu víme, pro koho je trasa určena a dopřesňujeme pro jasnou 
cílovou skupinu typ trasy (zjednodušeně lze říci, že všechny uvedené hodnoty
se mohou v praxi objevit u všech klíčů - a zde je právě zachycena ta 
vlastnost, že postačí jeden klíč a jedna skupina hodnot, aby zachytil mnoho 
reálných kombinací)

zde kaskáda končí a následuje sada solitérně stojících key=value. V návrhu 
schematu má nejdůležitější postavení definice toho, jak bude vykreslena 
barevná informace v renderu mapy:

osmc:symbol=* (vč. hodnoty none, příp. barva:none pro trasu s definovanou 
barvou ale bez fyzického výskytu liniového značeni)
asi není nutný komentář. Snad jen ten, že osmc:symbol=none není explicitně 
nesprávný sám o sobě a nejlépe (a nezvratně) definuje reálný stav věci - 
značka neexistuje. V tomto případě ponechá na rendereru, jak se zachová. 
Pokud z nějakého důvodu chci napovědět renderu, jakou barvou by měla (když 
už z rozhodnutí renderu bude) být linie trasy v mapě vykreslena, pak osmc:
symbol=green:none - toto je třeba příklad lokálních tras, které jsou 
zamalovány např. v nějaké místní mapě, mají dokonce i definovanou barvu pro 
případ, že jich je v lokalitě více, ale NEMAJÍ FYZICKÉ ZNAČENÍ v terénu. 
Render pak může rozlišit toto "nefyzické" značení např. tím, že vykreslí 
sice zeleně, ale čárkovaně


Praktické ukázky

Re: [Talk-es] Importación Catastral Bormujos

2016-06-09 Diskussionsfäden Alejandro S.

Si no recuerdo mal, había una idea que era juntar todas las parcelas
contiguas que tuvieran el mismo uso y con la unión de todas haber una área
que las cubriera con el landuse correspondiente, pero entonces se perdía la
información de muros de piedra de separación y tal.

On Thu, Jun 9, 2016, 12:09 Victor Grousset  wrote:

> On 08/06/2016 17:50, Alejandro S. wrote:
>
> ¿Al final se decidió importar los usos del suelo? ¿No quedó la cosa en que
> lo único que merecía la pena importar por ahora eran los edificios?
>
>
> Después de haber leído la pagina sobre las parcelas
> https://wiki.openstreetmap.org/wiki/Parcel
>
> Comprendo que no hay consenso para saber si hay que importarlas.
>
> Y aún menos sobre que tag usar.
>
> Entonces importarlas y ademas con un tag landuse seria un error.
> Porque mezclamos datos con semántica diferente.
> Y después no sera posible de separarlos en le caso de que un día sea
> decidido de importarlas y que sea con otro tag.
>
>
> --
> Victor Grousset
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-legal-talk] FYI Collective Database Guideline

Am 09.06.2016 um 17:36 schrieb Simon Poole:

>
> Am 09.06.2016 um 17:06 schrieb Robert Whittaker (OSM lists):
>> Also (and it may be deliberate) this guideline doesn't address the
>> question of what filtering / querying you can do with your collective
>> database. For instance, under the guideline I can take OSM restaurant
>> data, and add third-party ratings data to each entry, and it will be a
>> collective database. But what if I then do a query that returns the
>> locations of restaurants that have >4* ratings in a certain area and
>> just show those to users? Is this filtered dataset -- including the
>> ratings used to create it -- subject to share-alike, or is it still a
>> collective database of OSM restaurant names and locations, together
>> with independent ratings?
> I don't quite see the problem:
>
> - the OSM component of a Collective Database retains its licensing terms
> regardless of what you do with it.
> - if you don't create a database, you don't create a database. As the
> ODbL states you can use a Collective Database to create a Produced Work
> without creating an intermediate Derivative Database, typically on the
> fly generated results for display purposes will be Produced Works.
> - if you created a dataset from the filtered results and publicly used
> it, yes, likely you would have to honour a request for the OSM
> component  (which naturally would implicitly contain the information
> where those 4* restaurants are) TANSTAAFL.
>
> Simon
>
Small further note: the Collective Database guidelines assumes the same
as we do in the "Region Extract" guideline, that the geographic extent
of a OSM extract to not invoke share-alike/be a Derivative Database has
to be at least country size, that would naturally apply in your example
too, so creating smaller extracts would fall afoul of this rule.

Simon




signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] FYI Collective Database Guideline

2016-06-09 Diskussionsfäden Christoph Hormann

On Thursday 09 June 2016, Simon Poole wrote:
> I can understand the desire for a negative example, but:
>
> - this is documentation of use that we are happy with, not of the
> opposite.

But we are happy with uses that invoke share-alike as well, aren't we?

> - as the preamble says there may be other ODbL compliant ways that to
> not invoke share-alike to combine datasets outside of those detailed
> in the guideline.
>
> - using a contrived non-trivial negative example has the "it is
> definitely going to happen" problem that it will be seen as a ruling
> in use cases which are not on our table and of which we don't know
> the details.

I try to avoid getting again into a discussion on the guideline itself 
here (i voiced my concerns previously - no need to do this again at 
this point).  In any case it would be the first single sided guideline 
that does not draw a line between two fields of data use.

And as i read the text of the guideline it implies certain limits, for 
example

"non-OSM data completely replaces a particular type of geometry or data"

implies the situation is different in some way if it does not completely 
replace and

"uses either all OSM data or no OSM data for that property"

implies that a data mixture in properties changes the situation.

In other words: having precisely formulated points in parameter space 
but not having limits defined in relation to these points looks odd.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-legal-talk] FYI Collective Database Guideline



Am 09.06.2016 um 17:06 schrieb Robert Whittaker (OSM lists):
>
> Also (and it may be deliberate) this guideline doesn't address the
> question of what filtering / querying you can do with your collective
> database. For instance, under the guideline I can take OSM restaurant
> data, and add third-party ratings data to each entry, and it will be a
> collective database. But what if I then do a query that returns the
> locations of restaurants that have >4* ratings in a certain area and
> just show those to users? Is this filtered dataset -- including the
> ratings used to create it -- subject to share-alike, or is it still a
> collective database of OSM restaurant names and locations, together
> with independent ratings?
I don't quite see the problem:

- the OSM component of a Collective Database retains its licensing terms
regardless of what you do with it.
- if you don't create a database, you don't create a database. As the
ODbL states you can use a Collective Database to create a Produced Work
without creating an intermediate Derivative Database, typically on the
fly generated results for display purposes will be Produced Works.
- if you created a dataset from the filtered results and publicly used
it, yes, likely you would have to honour a request for the OSM
component  (which naturally would implicitly contain the information
where those 4* restaurants are) TANSTAAFL.

Simon



signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-talk-fr] Crédit licence données OdbL avec fond de carte Gmaps

2016-06-09 Diskussionsfäden Nicolas Dumoulin

Le Thu, 9 Jun 2016 16:58:43 +0200,
Florian LAINEZ  a écrit :

> Bonjour,
> Je me demande si le crédit « © les contributeurs d’OpenStreetMap »
> doit être apposé sur une carte affichant des POIs d'OSM avec un fond
> de carte Gmaps.
> 
> Je n'ai trouvé ce cas particulier ni dans le wiki ni sur la page
> http://www.openstreetmap.org/copyright
> 
> Merci pour vos réponses

Pour moi, c'est pourtant clair :
"Vous êtes libre de copier, *distribuer*, *transmettre* et adapter nos
données, à condition que vous créditiez, OpenStreetMap et ses
contributeurs."

Donc oui, OSM doit être crédité pour les POIs affichés.

-- 
Nicolas Dumoulin


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

Re: [Talk-cz] kct_neco=neco [was: Re: Cykloznačení - puntík se stříškou]

2016-06-09 Diskussionsfäden Jan Breuer

Dne 9. června 2016 14:13 Petr Vozdecký  napsal(a):

>
> -- Původní zpráva --
> Od: Jan Breuer 
>
>
> Dne 9. června 2016 11:29 Marián Kyral  napsal(a):
>
> Dotaz.
>
> Jak na papírové mapě poznáš, co to je za trasa? Že to je zrovna odbočka k
> pramenu? Vetšinou podle značky ne? A pak podle legendy. A tu legendu můžeš
> připravit na základě route=* a osmc:symbol=*.
>
>
> Nemapujeme přeci pro renderer, ne? Aktuálně to má asi skoro nulové
> využití, ale když už teď tu informaci máme, tak mě přijde škoda ji zahodit.
> Spoléhat na osmc:symbol prostě nejde vždy - viz vlákno puntík se stříškou.
>
>
> Honzo, díky za reakci,
>
>
> nedá mi než se nezeptat - co "má skoro nulové využití"? informace o barvě?
> To určitě ně. Ale my ji nezahazujeme, jen ji umisťujeme jinam a to dost
> jednoznačně. Do místa, kde má logiku a kde mu rozumí i v zahraničí.
>
>
>
Barva je jasná z osmc:symbol. Myslel jsem to, co je teď obsahem za
kct_barva, tedy major | local | learning | ruin | peak | spring |
interesting_object. Z diskuze některých jsem nabyl dojmu, že to není
potřeba, protože je to jasné z osmc:symbol, což není vždy pravda. Nic
duplikovat nechci. Tady jde ale o dvě různé informace. Značení daného
operátora a jeho konkrétní převod piktogramu na význam. Každý operátor má
jinou převodní tabulku.

Většina lidí si vystačí s osmc:symbol, protože se budou dívat na mapu na
papíře/v mobilu, takže toto jsem myslel tím "skoro nulovým využitím" tyto
dvě hodnoty rozlišovat, protože v 95% se skutečně dají mapovat 1:1 kvůli
majoritě KČT.

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

Re: [OSM-talk-fr] "Google et la SNCF cartographient les gares de l'Euro 2016"

2016-06-09 Diskussionsfäden Romain MEHUT

C'est complémentaire dixit "Gares et Connexions" cf.
https://twitter.com/ConnectGares/status/74079589557248

Le 9 juin 2016 à 15:20, Florian LAINEZ  a écrit :

> Hello,
> La SNCF est en effet composée de diverses entités plus ou moins
> indépendantes.
> "Gares et Connexions" a décidé de monter ce partenariat avec Google, et
> "Transilien" a fait le choix d'OSM.
>
> Ceci dit, et on peut en être fiers, la qualité du mapping est aujourd'hui
> objectivement meilleure dans OSM (cocorico youpi). A nous de prouver que
> cette qualité peut se maintenir dans le temps avec la participation de la
> communauté ... affaire à suivre.
>
> Vous pourrez comparer les deux options à la sortie de l'appli Transilien
> ce mois-ci. Je vous en informerai, bien entendu !
>
>
> Le 9 juin 2016 à 15:02, PanierAvide  a écrit :
>
>> C'est dommage, surtout vu l'effort qui est déployé par certains au sein
>> de la SNCF pour proposer le même type de données de manière ouverte dans un
>> écosystème d'outils libres (que l'on ne citera pas) :)
>>
>>
>> Le 09/06/2016 à 14:58, Christian Quest a écrit :
>>
>>> Encore une main gauche qui ne sait pas ce que fait celle de droite
>>> (et/ou inversement).
>>>
>>>
>>> Le 09/06/2016 à 14:32, Sylvain Maillard a écrit :
>>>
 Bonjour à tous,


 je viens de voir passer cet article sur la cartographie des gares par
 Google : "Les deux partenaires n'ont pas précisé le coût du projet"

 Dommage de dépenser des sous seulement pour "les développeurs qui
 utilisent des cartes Google" ...


 http://www.lefigaro.fr/flash-eco/2016/06/09/97002-20160609FILWWW00102-google-et-la-sncf-cartographient-les-gares-de-l-euro-2016.php


>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
>
> *Florian Lainez*
> @overflorian 
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Verwendung von Markenlogos in Karten?

2016-06-09 Diskussionsfäden Sven Geggus

Markus  wrote:

> Firmenlogos haben m.E. in einer (werbe-)freien Karte nichts zu suchen.

Unabhängig von der rechtlichen Lage sehe ich ehrlich gesagt wenige
Unterschiede zu sowas:
shop=supermarket
name=ALDI

Für mich sind die Firmenlogos genauso Fakten wie der zugehörige Name. Mit
Werbung hat das nichts zu tun.

Ein valides Argument zählt aber natürlich schon die weltweite Eindeutigkeit
von Logos. Allerdings ist die Zielgruppe für den deutschen Stil ja schon im
wesentlichen der deutschsprachige Raum.

Schon Supermarktketten aus den deutschsprachigen Nachbarländern kennt aber
wohl nicht mehr jeder und dann ist die Assoziation zu Supermarkt dahin.
Soweit habt ihr mich überzeigt. ALDI oder Migros Logos wird es nicht geben.

Ich sehe aber im deutschen Stil schon auch ein wenig die erlaubte Tendenz
der Weltkarte die deutsche Sicht der Dinge überzubraten :)

Warum sollten die weltweite Verwendung von orangen Autobahnen und blauen
Schildern OK sein, ein deutsches Posthorn aber nicht?

Ich will eine Karte wie ich sie gewohnt bin und da gehört nun mal auch dazu,
dass das Symbol für ein Polizeirevier keine Handschellen sind. Das finde ich
zu martialisch. Das Männchen in Uniform im aktuellen Carto ist aber OK.

Apropos deutsche Eigenheiten. Hat jemand ein schönes Logo für einen
Dönergrill? Der default Hamburger für amenity=fast_food passt da eigentlich
nicht so recht :)

Gruss

Sven

-- 
"Ich fürchte mich nicht vor der Rückkehr der Faschisten in der Maske der
Faschisten, sondern vor der Rückkehr der Faschisten in der Maske der
Demokraten" (Theodor W. Adorno)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] TEDi - Stores richtiger Name

2016-06-09 Diskussionsfäden Robert Whittaker (OSM lists)

Die "richtige", na ja mindestens eine, Lösung ist
https://github.com/osmlab/name-suggestion-index zu verwenden, sowohl in
iD wie auch vespucci wird es verwendet und kann auch das Tagging für
bestimmte Objekte vereinheitlichen falls das gewünscht wird.

Die effektive Liste auf github ist allerdings eher schlecht gepflegt,
man muss die also für sein jeweilge Anwendung selbst neu generieren.

SImon

Am 09.06.2016 um 13:12 schrieb DC Viennablog:
> Hallo allerseits,
> ich habe vor kurzem ein Geschäft der Linie "TEDi" in die OSM eingetragen. Da 
> laut LOGO, Website und eben auch vor Ort TEDi am Geschäft steht, heißt die 
> Geschäftslinie wohl so. Nach einer Overpass-turbo suche ergaben sich jedoch 
> etwa 80 "TEDi" und 210 "Tedi". Dennoch dachte ich, dass (da der Name ein 
> Akronym ist, das „TEDi“ geschrieben gehört) TEDi richtig ist, und besserte 
> das (ohne zu wissen, das sowas ein mechanischer Edit ist) österreich- und 
> deutschlandweit aus. Da aber nun (wohl insofern richtiger weise) der Edit von 
> Tedi auf TEDi wieder revertiert wurde, frage ich halt hier jetzt auch nach: 
> Wie soll jetzt das Geschäft gemappt werden?
>
> Ich persönlich kann es nicht ausstehen, wenn man ein Datenbanksystem hat (und 
> die OSM ist nicht anderes) und da sind ein und das selbe Ding (hier Filialen 
> von TEDi) in verschiedenen Schreibweisen und mit oft unterschiedlichen shop 
> Tags drinnen… Die Filialen scheinen alle ident zu sein. Also alles 
> variety-stores mit dem Namen TEDi...
>
> Im Sinne der Einheitlichkeit wäre hier die Findung einer Namenkonvention 
> (gerne auch in der OSM-WIKI dokumentiert) wünschenswert.
>
> Gibt es vielleicht einen Fall zum Exempel bezüglich Firmenschreibweisen?
>
> Hoffe hier weis wer Rat!
>
> Mit freundlichen Grüßen
> RobinD. (emergency99)
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de




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

Re: [OSM-legal-talk] FYI Collective Database Guideline

On 9 June 2016 at 13:08, Christoph Hormann  wrote:
> On Thursday 09 June 2016, Simon Poole wrote:
>>
>> The LWG has just forwarded the text of
>> http://wiki.openstreetmap.org/wiki/Collective_Database_Guideline to
>> the OSMF board for approval and publishing as definite guidance from
>> the OSMF.
>
> IIRC it was already noted by others that the lack of an example where
> share-alike applies kind of makes the whole thing appear unbalanced and
> endangers meeting the purpose to clarify 'where the line is drawn'.
>
> Independent of the actual content adding a non-trivial counter-example
> would IMO significantly improve practical usefulness and understanding
> of the guideline.

+1

Also (and it may be deliberate) this guideline doesn't address the
question of what filtering / querying you can do with your collective
database. For instance, under the guideline I can take OSM restaurant
data, and add third-party ratings data to each entry, and it will be a
collective database. But what if I then do a query that returns the
locations of restaurants that have >4* ratings in a certain area and
just show those to users? Is this filtered dataset -- including the
ratings used to create it -- subject to share-alike, or is it still a
collective database of OSM restaurant names and locations, together
with independent ratings?

I wonder if we'd be better having a guideline that's based on rule
that any data used in a query with OSM data has to be shared. Data
that's only used in simple table joins does not. (As in the existing
guideline, it would be a question of whether you can achieve the same
results using such a method. Technical implementations that do things
differently for efficiency reasons don't count against you.)

Robert.

-- 
Robert Whittaker

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

[OSM-talk-fr] Crédit licence données OdbL avec fond de carte Gmaps

2016-06-09 Diskussionsfäden Florian LAINEZ

Bonjour,
Je me demande si le crédit « © les contributeurs d’OpenStreetMap » doit
être apposé sur une carte affichant des POIs d'OSM avec un fond de carte
Gmaps.

Je n'ai trouvé ce cas particulier ni dans le wiki ni sur la page
http://www.openstreetmap.org/copyright

Merci pour vos réponses

-- 

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

Re: [OSM-legal-talk] FYI Collective Database Guideline

2016-06-09 Diskussionsfäden Robert Whittaker (OSM lists)

I can understand the desire for a negative example, but:

- this is documentation of use that we are happy with, not of the opposite.

- as the preamble says there may be other ODbL compliant ways that to
not invoke share-alike to combine datasets outside of those detailed in
the guideline.

- using a contrived non-trivial negative example has the "it is
definitely going to happen" problem that it will be seen as a ruling in
use cases which are not on our table and of which we don't know the
details.

A simple trivial example of common use that is not in line with the
guideline would be de-duplication of elements in OSM and a third party
dataset to generate a common  database. in which each object only exists
once.

Simon

Am 09.06.2016 um 14:08 schrieb Christoph Hormann:
> On Thursday 09 June 2016, Simon Poole wrote:
>> The LWG has just forwarded the text of
>> http://wiki.openstreetmap.org/wiki/Collective_Database_Guideline to
>> the OSMF board for approval and publishing as definite guidance from
>> the OSMF.
> IIRC it was already noted by others that the lack of an example where 
> share-alike applies kind of makes the whole thing appear unbalanced and 
> endangers meeting the purpose to clarify 'where the line is drawn'.
>
> Independent of the actual content adding a non-trivial counter-example 
> would IMO significantly improve practical usefulness and understanding 
> of the guideline.
>




signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-GB] RFC: Semi Automatic Import of schools

On 9 June 2016 at 10:50, Christian Ledermann
 wrote:
> I'd like to propose to use http://schools.mapthe.uk for a semi automatic 
> import
> of Ordonance Survey Open School grounds data combined with
> edubase and seed data into OpenStreetMap.
>
> The Tool is available at http://schools.mapthe.uk/
> The sourcecode and documentation is available at
> https://github.com/cleder/os-opendata-edubase
>
> My tests with this tool are very encouraging, I'd like to go forward
> to the imports mailing list with this proposal.

I have a quick look at your tool, but I'm afraid the instances I was
presented with initially left me rather confused about exactly what it
is doing and where the data is coming from. (I didn't read the github
readme to start with, as that looked from the start to be instructions
for installing the app yourself, rather than how to use it.) I think
that basic info should be provided on the page itself so users don't
have to go elsewhere to find  out what is what. It would also be good
to have a better description of how things are selected / matched up
between the datasets. In particular, is the tool trying to go through
all school polygons in OS Open Map, or just those matched to an
Edubase entry that doesn't have an existing ref:edubase match in OSM?
Are you just matching / showing things based on proximity to the
current OS Open Map polygon?

The first few things I was shown were as follows:

* http://schools.mapthe.uk/assign/22701/ -- The blue polygon seems to
be for a churchyard, not a school. Why/how was is chosen / matched? Is
it an error in OS Open Map perhaps?

* http://schools.mapthe.uk/assign/22591/ -- There's a school name but
no other data shown. Is this because there are no nearby edubase
entries? (It would be helpful if the page says so.) This might not
mean the site is not/no longer a school though, as it could be a
satellite site for a school with a main address elsewhere.

* http://schools.mapthe.uk/assign/5733/ -- The red area is an existing
OSM polygon, but this isn't made clear on the page. Also could the
full set of tags be shown in the section at the bottom, ideally as a
table?

A few other comments / suggestions:

* It would also be helpful if you could explicitly list the source
data items their key data explicitly on your page view (as you already
partially do with the OSM data) and also provide clickable links to
the OSM object (e.g. http://www.openstreetmap.org/way/148997325) and
full Edubase entry (e.g.
http://www.education.gov.uk/edubase/establishment/summary.xhtml?urn=111777)
to allow people to inspect them.

* In the case where you think an OSM object already exists, could
there be a button to add/replace the existing tags with the data you
think is appropriate (ideally with an option to overwrite or preserve
each existing tag that clashes)? Any maybe an option to completely
replace/update the geometry too -- though this is a bit dangerous, as
you'd have to be careful with what to do with the original nodes in
case they were also being used for other things.

* I don't think "os-open" is a suitable source tag if it's supposed to
be referring to OS Open Map Local. Using something approximating the
full name would be better as it is less ambiguous. "os-open" could be
mistaken for a general tag referring to any of the OS OpenData
products.

* The tags to be added would be easier to read if they were presented
as separate rows in a table.

* Could the map layer switcher be shown open all the time? Before
adding a polygon, one should really check the Satellite view, so this
would save a click each time.

* The height of the map view is annoying small on my large monitor.

* Are you looking for OSM nodes and relations as well as ways? (e.g.
at http://schools.mapthe.uk/assign/26893/ there's an existing node
that doesn't seem to be detected.)

* When there's no OSM data, the forwards and backwards links look like
they're in a box with a title "Openstreetmap Data", when they're
actually nothing to do with any OSM data. If there's no OSM data to
display, then you should either have some placeholder text to say so,
or omit the heading.

* The telephone numbers (phone=*) aren't in the international format
specified at http://wiki.openstreetmap.org/wiki/Key:phone .

Finally, from the few polygons I've looked at, they're not always that
accurate. In more than 50% of cases, I think I would want to do better
drawing it manually over the satellite imagery. I'm not convinced that
providing a tool that encourages / makes it easy for people to add
lower quality data is necessarily a good thing. Perhaps we need to
assess the accuracy of these polygons more carefully before
proceeding.

I hope some of this is useful...

Robert.

-- 
Robert Whittaker
http://robert.mathmos.net/osm/

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

[OSM-ja] OSM新パンフレットへ掲載する写真の募集について

2016-06-09 Diskussionsfäden Takahisa TAGUCHI


田口＠OSMFJです。

ただいまOSMFJでは、イベントやフィールドワークでの配布用に
新しいパンフレットを制作してます。

今までA4サイズ2つ折りと手のひらサイズの2タイプを用意していましたが、
今回制作しているのは手のひらサイズのリニューアル版となります。

予定通り制作が進めば8月のSotM Japanには配布できる見込みです。

今回のリニューアルでは、OSMを知らない方にも「マッピングの楽しさ」を
わかりやすく伝えるため、今までより明るいデザインとなる方向で制作が
進んでいます。

そこで、マッピングパーティ参加者が楽しくフィールドワークしている様子や
マッピング中に見つけたおもしろい風景等の写真をお持ちで「公開しても
いいよ！」という方がいらっしゃいましたら、6/12（日）までに
ご連絡いただけませんでしょうか。

写真の受け渡し方法は、クラウドストレージで共有してリンク先をご連絡
いただくか、直接メールへ添付して私宛てにご連絡ください。

※ いただいた写真は今回および今後作成するOSMパンフレット以外の目的では
　 無断で使用いたしません。ただし、作成したパンフレットは不特定多数の
　 方へ配布いたします。
※ 写真の掲載スペースには限りがあるため、パンフレット制作担当者で
　 集まった写真のなかから選定、編集させていただきます。
　 あらかじめご了承ください。

以上、よろしくお願いします。

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

Re: [Talk-it] Buongiorno, sono un nuovo iscritto

2016-06-09 Diskussionsfäden Martin Koppenhoefer



sent from a phone

> Il giorno 09 giu 2016, alle ore 15:00, Alessandro Srr 
>  ha scritto:
> 
> la mappa l'ho scaricata da garmin.openstreetmap.nl.
> 



prova a chiedere qui:
http://wiki.openstreetmap.org/wiki/Garmin.OpenStreetMap.nl#Bug_.2F_issue_reports



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

Re: [Talk-br] Buildings no OpenStreetMap

2016-06-09 Diskussionsfäden Roger C. Soares

Legal! Em Ribeirão Preto, SP, eu comecei a inspecionar os edifícios, eu 
desenho alguns e depois saio para coletar os dados, endereço, nome, nro 
de andares, ..., nada muito rápido, em geral eu coleto em regiões que eu 
passo. Se você quiser desenhar uns edifícios por aqui, eu vou achar bom :)


Atenciosamente,
Roger.

--
Em 09-06-2016 09:36, santamariense escreveu:

Pessoal, se alguém tiver interesse em mapear numeração de casas, lojas
e afins, eu me disponho a adicionar (desenhar) as "buildings=yes", o
que vai facilitar a coleta de dados, além de já deixar com melhor
precisão.

Mas, tem que ir a campo recolher numeração. Resumindo, eu desenho as
buildings da sua área de interesse com a condição que no mínimo seja
adicionada a numeração e nome da rua à casa.

Se alguém tiver interesse, é só se pronunciar a qualquer momento. Bons
mapeamentos a todos.

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



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

Re: [OSM-talk-fr] "Google et la SNCF cartographient les gares de l'Euro 2016"

2016-06-09 Diskussionsfäden Florian LAINEZ

Hello,
La SNCF est en effet composée de diverses entités plus ou moins
indépendantes.
"Gares et Connexions" a décidé de monter ce partenariat avec Google, et
"Transilien" a fait le choix d'OSM.

Ceci dit, et on peut en être fiers, la qualité du mapping est aujourd'hui
objectivement meilleure dans OSM (cocorico youpi). A nous de prouver que
cette qualité peut se maintenir dans le temps avec la participation de la
communauté ... affaire à suivre.

Vous pourrez comparer les deux options à la sortie de l'appli Transilien ce
mois-ci. Je vous en informerai, bien entendu !


Le 9 juin 2016 à 15:02, PanierAvide  a écrit :

> C'est dommage, surtout vu l'effort qui est déployé par certains au sein de
> la SNCF pour proposer le même type de données de manière ouverte dans un
> écosystème d'outils libres (que l'on ne citera pas) :)
>
>
> Le 09/06/2016 à 14:58, Christian Quest a écrit :
>
>> Encore une main gauche qui ne sait pas ce que fait celle de droite (et/ou
>> inversement).
>>
>>
>> Le 09/06/2016 à 14:32, Sylvain Maillard a écrit :
>>
>>> Bonjour à tous,
>>>
>>>
>>> je viens de voir passer cet article sur la cartographie des gares par
>>> Google : "Les deux partenaires n'ont pas précisé le coût du projet"
>>>
>>> Dommage de dépenser des sous seulement pour "les développeurs qui
>>> utilisent des cartes Google" ...
>>>
>>>
>>> http://www.lefigaro.fr/flash-eco/2016/06/09/97002-20160609FILWWW00102-google-et-la-sncf-cartographient-les-gares-de-l-euro-2016.php
>>>
>>>
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 

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

Re: [OSM-talk-fr] "Google et la SNCF cartographient les gares de l'Euro 2016"

2016-06-09 Diskussionsfäden Romain MEHUT

Le 9 juin 2016 à 14:58, Christian Quest  a écrit :

Encore une main gauche qui ne sait pas ce que fait celle de droite (et/ou
> inversement).


Pour ceux qui ne suivent pas https://challenge.sncf.com/open-street-map/ ;)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] "Google et la SNCF cartographient les gares de l'Euro 2016"

2016-06-09 Diskussionsfäden HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT ALCA APPUI PERFORMANCE)

Franchement cela commence à me foutre la pétoche : un si gros navire, plusieurs 
postes de commande et pas de pilote.
Et la croisière s'amuse.

-Message d'origine-
De : Christian Quest [mailto:cqu...@openstreetmap.fr] 
Envoyé : jeudi 9 juin 2016 14:58
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] "Google et la SNCF cartographient les gares de l'Euro 
2016"

Encore une main gauche qui ne sait pas ce que fait celle de droite (et/ou 
inversement).


Le 09/06/2016 à 14:32, Sylvain Maillard a écrit :
> Bonjour à tous,
>
>
> je viens de voir passer cet article sur la cartographie des gares par 
> Google : "Les deux partenaires n'ont pas précisé le coût du projet"
>
> Dommage de dépenser des sous seulement pour "les développeurs qui 
> utilisent des cartes Google" ...
>
> http://www.lefigaro.fr/flash-eco/2016/06/09/97002-20160609FILWWW00102-google-et-la-sncf-cartographient-les-gares-de-l-euro-2016.php
>


-- 
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] "Google et la SNCF cartographient les gares de l'Euro 2016"

2016-06-09 Diskussionsfäden PanierAvide

C'est dommage, surtout vu l'effort qui est déployé par certains au sein 
de la SNCF pour proposer le même type de données de manière ouverte dans 
un écosystème d'outils libres (que l'on ne citera pas) :)



Le 09/06/2016 à 14:58, Christian Quest a écrit :
Encore une main gauche qui ne sait pas ce que fait celle de droite 
(et/ou inversement).



Le 09/06/2016 à 14:32, Sylvain Maillard a écrit :

Bonjour à tous,


je viens de voir passer cet article sur la cartographie des gares par 
Google : "Les deux partenaires n'ont pas précisé le coût du projet"


Dommage de dépenser des sous seulement pour "les développeurs qui 
utilisent des cartes Google" ...


http://www.lefigaro.fr/flash-eco/2016/06/09/97002-20160609FILWWW00102-google-et-la-sncf-cartographient-les-gares-de-l-euro-2016.php 









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

Re: [Talk-it] Buongiorno, sono un nuovo iscritto

2016-06-09 Diskussionsfäden Alessandro Srr

Ciao,

come ho già scritto non avevo mai avuto problemi di questo tipo in passato. Il 
problema mi succede adesso con OSM generic routable e OSM generic routable 
(new...). La cosa strana è che se sposto un punto della retta dell'itinerario 
su una strada, il più delle volte (ma non sempre) mi calcola correttamente 
l'itinerario la mappa l'ho scaricata da  garmin.openstreetmap.nl.

Grazie ocmunque della risposta.

A.

From: iw1...@gmail.com
Date: Thu, 9 Jun 2016 08:19:06 +0200
To: talk-it@openstreetmap.org
Subject: Re: [Talk-it] Buongiorno, sono un nuovo iscritto

Ciao Alessandro.

Potrebbe dipendere dal file TYP presente nella mappa, che non è routable, in 
pratica non è del tipo che permette la navigazione ed il calcolo 
dell'itinerario.

Prova a caricare un' altra mappa, sempre basata su osm, quasi di sicuro risolvi 
il problema.

Il 7 Giugno 2016 14:41:30 CEST, Alessandro Srr  ha 
scritto:



Mi sto appassionando al mondo GPS e pertanto era impossibile non passare da 
queste parti 
Ho 59 anni, sono un moto-viaggiatore (moto-turista non mi piace) e avevo 
intenzione di usare la mappa OSM generic router (italia-slovenia-croazia) 
affiancata alla ufficiale Garmin. Ho un mac sul quale ho installato BaseCamp 
4.6.3. Nessun problema per aggiungere la mappa OSM generic routable ma, 
sorpresa sorpresa, BaseCamp con questa mappa calcola gli itinerari 
correttamente solo in modalità fuoristrada, pedonale, bici, ecc., ma se imposto 
alla guida, moto, moto panoramica ecc. (ovvero per utilizzare strade e non 
sentieri o similari) mi traccia solo una linea retta. Vorrei precisare che in 
passato, con altre versioni di BaseCamp e di mappe OSM, non ho mai avuto 
problemi di questo tipo. Non sono quindi in gradi di dire se si tratti idi un 
problema di BaseCamp o
di mappa. Ci sono altri che hanno incontrato (si sono scontrati) con questo 
problema? Nel caso, come lo hanno risolto?
Ringrazio anticipatamente chiunque sia disposto a darmi una mano e gli altri 
che hanno avuto la pazienza di leggermi.

Alessandro

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


-- 

iw1gfv.it

piemontegps.altervista.org

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

Re: [OSM-talk-fr] "Google et la SNCF cartographient les gares de l'Euro 2016"

2016-06-09 Diskussionsfäden Christian Quest

Encore une main gauche qui ne sait pas ce que fait celle de droite 
(et/ou inversement).



Le 09/06/2016 à 14:32, Sylvain Maillard a écrit :

Bonjour à tous,


je viens de voir passer cet article sur la cartographie des gares par 
Google : "Les deux partenaires n'ont pas précisé le coût du projet"


Dommage de dépenser des sous seulement pour "les développeurs qui 
utilisent des cartes Google" ...


http://www.lefigaro.fr/flash-eco/2016/06/09/97002-20160609FILWWW00102-google-et-la-sncf-cartographient-les-gares-de-l-euro-2016.php




--
Christian Quest - OpenStreetMap France


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

[OSM-talk-fr] "Google et la SNCF cartographient les gares de l'Euro 2016"

2016-06-09 Diskussionsfäden Sylvain Maillard

Bonjour à tous,


je viens de voir passer cet article sur la cartographie des gares par
Google : "Les deux partenaires n'ont pas précisé le coût du projet"

Dommage de dépenser des sous seulement pour "les développeurs qui utilisent
des cartes Google" ...

http://www.lefigaro.fr/flash-eco/2016/06/09/97002-20160609FILWWW00102-google-et-la-sncf-cartographient-les-gares-de-l-euro-2016.php


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

Re: [OSRM-talk] new api table and geometry

2016-06-09 Diskussionsfäden Michal Palenik

i've added a feature request
https://github.com/Project-OSRM/osrm-backend/issues/2519



the unpacking of edges phase should allow for impedance vs. speed debate
to move, also allowing for elevation to be stored in osrm.
i've tried to say this in my last comment at
https://github.com/Project-OSRM/osrm-backend/issues/77


michal
On Fri, Apr 15, 2016 at 10:27:40PM +0200, Michal Palenik wrote:
> daniel, 
> 
> thanks for the explanations.
> 
> my need to calculate (and show) only 1x15 matrix blurred my vision of
> all the problems :)
> 
> what I try to achieve is multimodal routing (foot+bus+foot) by showing
> three geometries combined into one (plus some instructions).
> 
> michal
> 
> On Fri, Apr 15, 2016 at 12:56:20PM -0700, Daniel Patterson wrote:
> > Michal,
> > 
> >   Strangely enough, we don't actually have the geometry.  We find a path 
> > across the Contraction Heirachy
> >   routing graph, this may only have a small handful of edges.  We can sum 
> > these edges to get the route
> >   duration, but to get the actual geometry or distance, we then have to 
> > "unpack" those edges.
> > 
> >   The table plugin doesn't do this unpacking step.  It gets the durations 
> > easily, but would be significantly slower
> >   if we also had to report back the route geometries.  The API response 
> > would probably also be huge (10s or 100's of MB?) for any
> >   non-trivial number of route pairs in the table.  To support that, we 
> > would need a way to stream the response
> >   asynchronously to the HTTP client, otherwise a couple of requests could 
> > use up all the RAM on the server.
> > 
> >   Things are never as simple as they seem :-(
> > 
> > daniel
> > 
> > > On Apr 15, 2016, at 12:45 PM, Michal Palenik  
> > > wrote:
> > > 
> > > that is what I already do, but it means a lot of (unnecessary)
> > > connections. I assume the geometries are already available when
> > > computing the duration. 
> > > 
> > > I was hoping for a "documentation lacking behind development"
> > > scenario... 
> > > 
> > > 
> > > cheers, 
> > > michal
> > > 
> > > On Fri, Apr 15, 2016 at 04:09:49PM +0200, Daniel Hofmann wrote:
> > >> If you check the v5 spec you linked, you will see only Route, Trip and
> > >> Match providing a "geometries" option.
> > >> 
> > >> What you can do is this:
> > >> - do a Table request from your position against all Bus / Tram stops in 
> > >> the
> > >> area / in a buffer of a few kilometers
> > >> - pick n shortest routes from the Table response and temporarily store
> > >> their destination coordinates
> > >> - do n Route request from your position against the n destination
> > >> coordinates and extract the geometry
> > >> 
> > >> Cheers,
> > >> Daniel J H
> > >> 
> > >> On Fri, Apr 15, 2016 at 3:49 PM, Michal Palenik 
> > >> 
> > >> wrote:
> > >> 
> > >>> hi,
> > >>> 
> > >>> within the new api, I am trying to find how to get geometry (together
> > >>> with perfect duration). is it possible?
> > >>> 
> > >>> or do I have to make N*M queries for all the possible combinations?
> > >>> 
> > >>> 
> > >>> https://github.com/Project-OSRM/osrm-backend/wiki/New-Server-api#service-table
> > >>> 
> > >>> I am trying to make a service like "show me the routes to the closest
> > >>> bus/tram stops" : http://epsilon.sk/mhd/
> > >>> 
> > >>> thanks
> > >>> 
> > >>> michal
> > >>> 
> > >>> --
> > >>> michal palenik
> > >>> www.freemap.sk
> > >>> www.oma.sk
> > >>> 
> > >>> 
> > >>> ___
> > >>> OSRM-talk mailing list
> > >>> OSRM-talk@openstreetmap.org
> > >>> https://lists.openstreetmap.org/listinfo/osrm-talk
> > >>> 
> > > 
> > >> ___
> > >> OSRM-talk mailing list
> > >> OSRM-talk@openstreetmap.org
> > >> https://lists.openstreetmap.org/listinfo/osrm-talk
> > > 
> > > 
> > > -- 
> > > michal palenik
> > > www.freemap.sk
> > > www.oma.sk
> > > 
> > > 
> > > ___
> > > OSRM-talk mailing list
> > > OSRM-talk@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/osrm-talk
> > 
> > 
> > ___
> > OSRM-talk mailing list
> > OSRM-talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/osrm-talk
> 
> -- 
> michal palenik
> www.freemap.sk
> www.oma.sk
> 
> 
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk

-- 
michal palenik
www.freemap.sk
www.oma.sk


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

Re: [OSM-legal-talk] FYI Collective Database Guideline

2016-06-09 Diskussionsfäden Christoph Hormann

On Thursday 09 June 2016, Simon Poole wrote:
>
> The LWG has just forwarded the text of
> http://wiki.openstreetmap.org/wiki/Collective_Database_Guideline to
> the OSMF board for approval and publishing as definite guidance from
> the OSMF.

IIRC it was already noted by others that the lack of an example where 
share-alike applies kind of makes the whole thing appear unbalanced and 
endangers meeting the purpose to clarify 'where the line is drawn'.

Independent of the actual content adding a non-trivial counter-example 
would IMO significantly improve practical usefulness and understanding 
of the guideline.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-cz] kct_neco=neco [was: Re: Cykloznačení - puntík se stříškou]

-- Původní zpráva --
Od: Jan Breuer

Dne 9. června 2016 11:29 Marián Kyral napsal(a):
"
Dotaz.

Jak na papírové mapě poznáš, co to je za trasa? Že to je zrovna odbočka k
pramenu? Vetšinou podle značky ne? A pak podle legendy. A tu legendu můžeš
připravit na základě route=* a osmc:symbol=*.

"
Nemapujeme přeci pro renderer, ne? Aktuálně to má asi skoro nulové využití,
ale když už teď tu informaci máme, tak mě přijde škoda ji zahodit. Spoléhat
na osmc:symbol prostě nejde vždy - viz vlákno puntík se stříškou.

Honzo, díky za reakci,

nedá mi než se nezeptat - co "má skoro nulové využití"? informace o barvě?
To určitě ně. Ale my ji nezahazujeme, jen ji umisťujeme jinam a to dost
jednoznačně. Do místa, kde má logiku a kde mu rozumí i v zahraničí.

Právě teď, kdy jsme se při mapování (ne)značených tras dostali až do toho
bodu, kdy si uvědomujeme přítomnost jiných než turistických tras "červená/
modrá/zelená/žlutá" KČT, je správné si stanovit JAKÉ hodnoty je potřeba
sledovat (tagovat, čili uchovat). Nicméně asi bych nesouhlasil s tím, že je
potřeba tagovat osmc:symbol=blue:něco a PRO JISTOTU ještě někam napsat
"modrá". Pro jistotu, co kdyby se to ztratilo. Správně je naopak tagy
neduplikovat. A to právě tehdy, když si musíme uvědomit, že těch informací o
barvě musíme sledovat více než jednu (jak by to vypadalo, když bychom každou
duplikovali, nebo nedej bože duplikovali pro jisotu úplně každou hodnotu
každého tagu zapsaného do OSM databáze).

Proč to píšu? Protože chci říct, že zjišťujeme, že ke správnému popsání tras
vytvořených za různým účelem a pro různého uživatele atd. bude potřeba více
tagů a k jednoznačnosti a přehlednosti přispěje právě cílené vyhýbání se
nadbytečným informacem, resp. konkrétně duplicitám.

BTW: červený puntík se stříškou není nic jiného, než osmc:symbol=red:red_
round - je to na mapě červená linie a v terénu červené kolečko. Ta stříška
jen udává směr - úplně stejně jako KČT šipky na stromech, když trasa
odbočuje z předpokládaného směru.

vop

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

Re: [Talk-it] utilizzo ford=yes su piccoli torrenti/ruscelli asciutti (o quasi)

2016-06-09 Diskussionsfäden Alberto Nogaro

>-Original Message-
>From: demon.box [mailto:e.rossin...@alice.it]
>Sent: giovedì 9 giugno 2016 10:28
>To: talk-it@openstreetmap.org
>Subject: [Talk-it] utilizzo ford=yes su piccoli torrenti/ruscelli asciutti (o 
>quasi)

>
>1 - tutti i piccoli torrenti, torrentelli e ruscelli presenti sulle CTR (anche 
>se poi
>nella realtà sono più o meno visivamente evidenti perchè sono quasi sempre
>asciutti soprattutto a quote basse) vanno comunque mappati o lasciati se
>esistono già (non ero di questa idea inizialmente ma poi ragionando con voi
>alla fine mi trovo pienamente d'accordo).

+1 sul lasciare le vie d'acqua, anche se quasi sempre asciutte. Però bisogna 
anche tenere presente che le CTR non sono infallibili, o l'orografia localmente 
può essere cambiata rispetto a quando sono state compilate. Se proprio la via 
d'acqua non si vede in alcun modo, direi che la si può togliere.

>ovviamente se è il caso sul tag waterway si aggiunge intermittent=yes

Si, stando però attenti a non estendere una osservazione locale ad un corso 
d'acqua troppo lungo. Per la parte a monte del punto di osservazione dovrebbe 
essere abbastanza scontato, a parte fenomeni particolari di flusso sotterraneo. 
Per la parte a valle, è da valutare. Se non si è sicuri, meglio fermarsi almeno 
dove si innestano degli affluenti.

Ciao,
Alberto





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

Re: [Talk-cz] kct_neco=neco [was: Re: Cykloznačení - puntík se stříškou]

-- Původní zpráva --

Od: Karel Volný 


"> > nepochopil jsem body 5 a 6"
řeknu to "česky" - bod 5 a 6 říká: "kct_barva=* plete do sebe dve veci, ty 
prehledne rozdelime na dve hromadky a priradime prehledne kam patri. 
Konkretne vezmeme "major | local | learning | ruin | peak | spring | 
interesting_object" a budeme s nimi oznacovat to, co vyjadruji, tedy typ 
trasy z pohledu dulezitosti resp. cile, PROC byly vytvoreny, a pak vezmeme 
zbyle "horse | ski | bicycle | wheelchair" a dame je tam, kde budou nejlepe 
oznacovat to, co vyjadruji, tedy typ trasy z pohledu toho, PRO KOHO byly 
vytvoreny.
"

to nechápu ... jak lze horse atd. definovat 'pomocí "nadřazeného" tagu route
=*' jestliže tento už má hodnotu route=hiking?"
pokud jsem to v textu zpatlal a spatlal tak, že je to nesrozumitelné, pak 
odkazuji na předešlý mail. Tam je to IMHO zřejmé

"

> > dále navržené schéma samo porušuje bod 3, navíc o něm obdobně platí 
výtka,
> > kterou jsem měl v minulém mailu, že to nedává intuitivně smysl
> Bohužel se tu duplikuje stejný seznam hodnot pro všechny klíče hiking, 
ski, bicycle, wheelchair... což je asi to, na co narážíš?
ne tak úplně - narážím na to, že hodnota je vyjádřena přímo názvem klíče, 
což je v tom bodě 3 kritizováno"
ano, vypadá to tak, ale není to tak. Kct_barva=* stálo samo o sobě a POUZE 
na straně klíče. A při tom SOUČASNĚ vyjadřovalo HODNOTU, která už pak na 
straně hodnoty nikde nebyla uvedena. Navrhované schema (pokud zůstane v 
kaskádové podobě, předchozí mail nevylučuje i jiné jednoduché řešení při 
zachování celého principu jednoznačnosti a přehlednosti) nestaví hodnotu do 
klíče, ale napřed nastaví hodnotu a tu pak ROZVINE dále tím, že ji zopakuje 
v klíči. Je z tohoto popisu zřejmý (pochopitelný) rozdíl?

"
takže máme např. horse=yes, horse=designated ... jak do toho zapadne horse=
learning a co z toho pochopí "náhodný čtenář"?"
Náhodný čtenář nesmí číst náhodně. Musí číst v kontextu. Pokud otaguji 
relaci v souladu s navrhovaným schematem jako horse=learning, je zřejmé, že 
jakýkoliv tag horse=yes nebo horse=designated je jen zmatečnou duplicitou. 
Tag horse=learning už sám o sobě říká, že je to stezka určená pro koně, 
takže doplňovat ji horse=yes nebo horse=designated je opravdu zbytečné

"

> Ideální by bylo zavést tag, nezávislý na způsobu přepravy,
> nezávislý na barvě a nezávislý na operátoru - tedy bez
> velkého přemýšlení něco jako route:purpose=learning?
> Znásilnění tagu network se stejným účelem by mělo
> příliš mnoho vedlejších efektů.

souhlas, tag určující účel trasy v tomto smyslu by měl stát stranou"
ano, přesně to je ta "nekaskádová" varianta, o které píši v předchozím 
mailu. Jen s tím rozdílem, že jsem navrhoval route_type=* V tuto chvíli je 
jedno, jaké bude textové znění značky, ale jde o určení principu a základní 
kostry celého schematu

"

a já bych šel ještě kousek dál, podle mého by se měl dát aplikovat na 
jednotlivé cesty v relaci, pořád si myslím, že by "ocásky" měly být součástí
trasy, na kterou jsou napojeny (popř. tedy řešit to ne na úrovni cest, ale 
relace relací, třeba)"
Navidím šťastné vytvářet nelineární trasy (relace (ne)značené trasy, která 
nemá právě dva konce). Především mám na mysli jednodušší routování, resp. 
generování popisu cesty. Prostě jdu po "žlutá" až na rozcestník "U potoka" a
odbočím na "žlutá-pramen" a jdu až k rozcestníku "Pramen potoka".

"

> Tady musím souhlasit s Karlem, osmc:symbol by podle
> mě měl nést informaci pouze o symbolu. Bohužel stále
> máme pocit, že kčt je jediný, kdo tvoří trasy. Pak ale
> někdo (ne-kčt) vytvoří trasu a dá ji značky úplně podle
> sebe. Musíme tedy mít schema, které jednoznačně
> definuje odbočku k prameni pro lyžaře, i když je
> značená růžovým srdíčkem na fialovém podkladě.

souhlas, napsal jsi to lépe než já"
Zde nevidím u navrhovaného schematu jediný problém - a právě s tímto ohledem
bylo vytvářeno, Příklad tagování situace uvedené výše je v předchozím mailu 

"
například s tím horse, my máme puntík, a na OSM wiki je jako ilustrační 
obrázek route=horse bílá podkova na modrém podkladu"
Ve skutečnosti je to tak, že v ČR jsou navrženy k užití oba symboly "puntík"
i "podkova". Pokud mě paměť neklame, pak puntík je pro trasu z A do B a 
podkova pro okružní trasu. V obou případech jde o koňskou stezku
.




vop

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

Re: [Talk-de] TEDi - Stores richtiger Name

2016-06-09 Diskussionsfäden Alexander Heinlein

Hallo,

es gibt auch noch weitere Schreibweisen, bspw. T€Di, T€DI und T€di (siehe
https://taginfo.openstreetmap.org/search?q=name%3DT%E2%82%ACdi). Die sind
auch schon auf https://wiki.openstreetmap.org/wiki/WikiProject_Germany/Shops
vermerkt. Bei dieser Wiki-Seite geht es aber anscheinend nicht um das
Verwenden von einheitlichen Namen sondern darum, dass die anderen Tags
(shop=* etc.) möglichst einheitliche Werte haben sollen.

Grüße
Alex

> Gesendet: Donnerstag, 09. Juni 2016 um 13:12 Uhr
> Von: "DC Viennablog" 
> An: "talk-de@openstreetmap.org" 
> Betreff: [Talk-de] TEDi - Stores richtiger Name
>
> Hallo allerseits,
> ich habe vor kurzem ein Geschäft der Linie "TEDi" in die OSM eingetragen. Da 
> laut LOGO, Website und eben auch vor Ort TEDi am Geschäft steht, heißt die 
> Geschäftslinie wohl so. Nach einer Overpass-turbo suche ergaben sich jedoch 
> etwa 80 "TEDi" und 210 "Tedi". Dennoch dachte ich, dass (da der Name ein 
> Akronym ist, das „TEDi“ geschrieben gehört) TEDi richtig ist, und besserte 
> das (ohne zu wissen, das sowas ein mechanischer Edit ist) österreich- und 
> deutschlandweit aus. Da aber nun (wohl insofern richtiger weise) der Edit von 
> Tedi auf TEDi wieder revertiert wurde, frage ich halt hier jetzt auch nach: 
> Wie soll jetzt das Geschäft gemappt werden?
> 
> Ich persönlich kann es nicht ausstehen, wenn man ein Datenbanksystem hat (und 
> die OSM ist nicht anderes) und da sind ein und das selbe Ding (hier Filialen 
> von TEDi) in verschiedenen Schreibweisen und mit oft unterschiedlichen shop 
> Tags drinnen… Die Filialen scheinen alle ident zu sein. Also alles 
> variety-stores mit dem Namen TEDi...
> 
> Im Sinne der Einheitlichkeit wäre hier die Findung einer Namenkonvention 
> (gerne auch in der OSM-WIKI dokumentiert) wünschenswert.
> 
> Gibt es vielleicht einen Fall zum Exempel bezüglich Firmenschreibweisen?
> 
> Hoffe hier weis wer Rat!
> 
> Mit freundlichen Grüßen
> RobinD. (emergency99)
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>

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

[OSM-legal-talk] FYI Collective Database Guideline

FYI

The LWG has just forwarded the text of
http://wiki.openstreetmap.org/wiki/Collective_Database_Guideline to the
OSMF board for approval and publishing as definite guidance from the OSMF.

Simon




signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-es] Importación Catastral Bormujos

2016-06-09 Diskussionsfäden Moises Arcos

El 9 de junio de 2016, 12:09, Victor Grousset  escribió:

> On 08/06/2016 17:50, Alejandro S. wrote:
>
> ¿Al final se decidió importar los usos del suelo? ¿No quedó la cosa en que
> lo único que merecía la pena importar por ahora eran los edificios?
>
>
> Después de haber leído la pagina sobre las parcelas
> https://wiki.openstreetmap.org/wiki/Parcel
>
> Comprendo que no hay consenso para saber si hay que importarlas.
>
> Y aún menos sobre que tag usar.
>
> Entonces importarlas y ademas con un tag landuse seria un error.
> Porque mezclamos datos con semántica diferente.
> Y después no sera posible de separarlos en le caso de que un día sea
> decidido de importarlas y que sea con otro tag.
>

Por tanto según lo que comentas, en cada importación que hayamos realizado
hay que eliminar la geometría de la parcela???


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

Re: [Talk-cz] kct_neco=neco [was: Re: Cykloznačení - puntík se stříškou]


Ahoj vsem, ktere dane tema zajima (ostatni to preskocte, je to dlouhy... :o)

navrh zmeny tagovaciho schematu uverejneny v CZ Weekly 301 mel za ukol 
vyvolat diskusi (nelze se domnivat, ze je bez vad, dokonaly, 
vsepodchycujici...), coz se stalo jen okrajove. Soucasna debata ukazuje, ze 
existuji otazky, ktere si zaslouzi odpoved.

Prostor ve Weekly nebyl takovy, aby bylo mozne (vhodne) tam placat dlouhe 
texty, vysvetleni, priklady. Ano, bod 5 a 6 je tak kvuli tomu napsan tak 
"pravnicky", nemusi byt pochopitelny. Ostatne i jako jine pasaze textu.

Cili nyni zkusim napsat trochu vice.

Cilem bylo
1) ZCELA odstranit tag kct_barva=* Duvody jsou popsany, jsou zrejme. Cely 
navrh vychazi z toho, ze tento zamer a jeho zduvodneni (argumenty, cile) 
jsou nepopiratelne.
2) Narovnat logiku tagovani zachovanim (obnovenim) stromove (kaskadove) 
struktury
3) Vytvorit moznost tagovat vsechny kombinace (ne)znacenych tras, ktere se u
nas vyskytuji (protoze jsme svetovy extrem) a to jednak zachovanim plne 
kompatibility pro vnejsi svet (to dnes nemame), pripadne vytvorenim 
schematu, ktery lze od nas jako od zeme, ktera se s tim musela vyporadat 
ponekud obsirneji, prevzit

Co lze rozumet pod pojmem "stromova struktura". Neco jako:
objekt=zivocich
zivocich=savec
savec=pes
Ono by sice slo napsat objekt=pes, ale pokud z nejakeho duvodu chceme 
sledovat  i ty ostatni veliciny, musime je tak jako tak otagovat a prave 
stromova struktura nabizi pridanou hodnotu vyuziti kaskadoveho dedeni 
vlastnosti, sledovani jednoznacne nadrazenosti dane hodnoty (! a toto v 
nasem pripade predevsim) apod. A krom jiného - pokud je dobře navržena, pak 
tam, kde existuje příliš mnoho kombinací a sledovaných vlastností, popíše je
na minimu klíčů

Obdobne v OSM uzivame kaskadu treba zde:
landuse=construction
construction=farmland

Navrhovane schema rika (po jednotlivych vrstvach kaskady):
type=route
definujeme, ze relace (pripominam, ze tagujeme relaci) je nejaka trasa, tedy
linie, u znacenych (i neznacenych) tras bude pouzit VZDY tento tag, protoze 
vsechny trasy maji tuto vlastnost 

route=foot | hiking | bicycle | ski | horse | wheelchair
v tomto levelu kaskady definujeme trase vlastnosti, ktere je nejvice 
rozlisuji (maji nejvyssi vliv na dalsi uziti, nejvice rozdeluji cilove 
skupiny uzivatelu, maji vliv na vykresleni apod., napr. se vykresluji v 
zimnich/letnich mapach). Jsou to skupiny (zjednodušený český význam) 
"vycházková | turistická | cyklistická | lyžařská | koňská | vozíčkářská". 
Zde bych poznamenal, že v reálných podmínkách České republiky existuje 
specifický průnik mezi "hiking" a "bicycle" a tím jsou tzv. 
"cykloturistické" trasy KČT. Jsou to trasy vedené zpravidla lesem, značené 
směrníky typově shodnými jako turistické značení a terénní značky jsou 
podobně jako turistické "white+color:bar", ale fyzicky větší v podobě 
"yellow+color_bar". Tyto trasy nejsou v navrhovaném schematu zatím rozlišeny
a je skutečně vhodné k diskusi, zda a jak je rozlišit samostatným tagem v 
této úrovni kaskády, např. route=cycletourist - to proto, abychom opravdu 
jednoznačně odlišili "silniční" cykloturistiku (vedenou po cyklotrasách a 
cyklostezkách) od terénní cykloturistiky.

foot | hiking | bicycle | ski | horse | wheelchair=major | local | learning 
| ruin | peak | spring | interesting_object
v tomto levelu víme, pro koho je trasa určena a dopřesňujeme pro jasnou 
cílovou skupinu typ trasy (zjednodušeně lze říci, že všechny uvedené hodnoty
se mohou v praxi objevit u všech klíčů - a zde je právě zachycena ta 
vlastnost, že postačí jeden klíč a jedna skupina hodnot, aby zachytil mnoho 
reálných kombinací)

zde kaskáda končí a následuje sada solitérně stojících key=value. V návrhu 
schematu má nejdůležitější postavení definice toho, jak bude vykreslena 
barevná informace v renderu mapy:

osmc:symbol=* (vč. hodnoty none, příp. barva:none pro trasu s definovanou 
barvou ale bez fyzického výskytu liniového značeni)
asi není nutný komentář. Snad jen ten, že osmc:symbol=none není explicitně 
nesprávný sám o sobě a nejlépe (a nezvratně) definuje reálný stav věci - 
značka neexistuje. V tomto případě ponechá na rendereru, jak se zachová. 
Pokud z nějakého důvodu chci napovědět renderu, jakou barvou by měla (když 
už z rozhodnutí renderu bude) být linie trasy v mapě vykreslena, pak osmc:
symbol=green:none - toto je třeba příklad lokálních tras, které jsou 
zamalovány např. v nějaké místní mapě, mají dokonce i definovanou barvu pro 
případ, že jich je v lokalitě více, ale NEMAJÍ FYZICKÉ ZNAČENÍ v terénu. 
Render pak může rozlišit toto "nefyzické" značení např. tím, že vykreslí 
sice zeleně, ale čárkovaně


Praktické ukázky můžeme začít právě oním diskutovaným případem "tečka se 
stříškou":
type=route
route=foot | hiking | bicycle | ski | horse | wheelchair
foot | hiking | bicycle | ski | horse | wheelchair=major | local | learning 
| ruin | peak | spring | interesting_object
osmc:symbol=red:red_round
name=TRASA A - Bikemaraton Drásal
network=lwn

Re: [Talk-de] Verwendung von Markenlogos in Karten?

2016-06-09 Diskussionsfäden Markus

Hallo Sven,

> markus schnalke  wrote:
> 
>> Symbole haben gerade den Vorteil, dass sie moeglichst weitreichend
>> verstaendlich sind. 

Ja, Karten-Symbole müssen international verständlich
und in einer Weltkarte m.E. weltweit einheitlich sein.

> Apothekensymbol 
> Ich tendiere dazu stattdessen das grüne Kreuz zu verwenden.

:-) - kenne ich aus AT, CH, DE, IT, FR, GR, etc.

Ein Supermarkt ist ein Supermarkt
(auch wenn in GR jeder Minimarkt "Supermarket" heisst)
Die Unterscheidung findet sich dann im Namen (Migros, etc)

Genauso für Bahnhof, Restaurant, Hotel, Tankstelle, etc.
Es geht immer um die Funktion.

Firmenlogos haben m.E. in einer (werbe-)freien Karte nichts zu suchen.

Gruss, Markus

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

[Talk-de] TEDi - Stores richtiger Name

2016-06-09 Diskussionsfäden DC Viennablog

Hallo allerseits,
ich habe vor kurzem ein Geschäft der Linie "TEDi" in die OSM eingetragen. Da 
laut LOGO, Website und eben auch vor Ort TEDi am Geschäft steht, heißt die 
Geschäftslinie wohl so. Nach einer Overpass-turbo suche ergaben sich jedoch 
etwa 80 "TEDi" und 210 "Tedi". Dennoch dachte ich, dass (da der Name ein 
Akronym ist, das „TEDi“ geschrieben gehört) TEDi richtig ist, und besserte das 
(ohne zu wissen, das sowas ein mechanischer Edit ist) österreich- und 
deutschlandweit aus. Da aber nun (wohl insofern richtiger weise) der Edit von 
Tedi auf TEDi wieder revertiert wurde, frage ich halt hier jetzt auch nach: Wie 
soll jetzt das Geschäft gemappt werden?

Ich persönlich kann es nicht ausstehen, wenn man ein Datenbanksystem hat (und 
die OSM ist nicht anderes) und da sind ein und das selbe Ding (hier Filialen 
von TEDi) in verschiedenen Schreibweisen und mit oft unterschiedlichen shop 
Tags drinnen… Die Filialen scheinen alle ident zu sein. Also alles 
variety-stores mit dem Namen TEDi...

Im Sinne der Einheitlichkeit wäre hier die Findung einer Namenkonvention (gerne 
auch in der OSM-WIKI dokumentiert) wünschenswert.

Gibt es vielleicht einen Fall zum Exempel bezüglich Firmenschreibweisen?

Hoffe hier weis wer Rat!

Mit freundlichen Grüßen
RobinD. (emergency99)
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-cz] kct_neco=neco [was: Re: Cykloznačení - puntík se stříškou]

2016-06-09 Diskussionsfäden Marián Kyral



-- Původní zpráva --
Od: Jan Breuer 
Komu: OpenStreetMap Czech Republic 
Datum: 9. 6. 2016 12:01:43
Předmět: Re: [Talk-cz] kct_neco=neco [was: Re: Cykloznačení - puntík se 
stříškou]

"





Dne 9. června 2016 11:29 Marián Kyral  napsal(a):
"
Dotaz.


Jak na papírové mapě poznáš, co to je za trasa? Že to je zrovna odbočka k 
pramenu? Vetšinou podle značky ne? A pak podle legendy. A tu legendu můžeš 
připravit na základě route=* a osmc:symbol=*.




"
Nemapujeme přeci pro renderer, ne? Aktuálně to má asi skoro nulové využití, 
ale když už teď tu informaci máme, tak mě přijde škoda ji zahodit. Spoléhat 
na osmc:symbol prostě nejde vždy - viz vlákno puntík se stříškou.






"



Ne nemapujeme. To byl jen příklad, jak ukázat,  co je minimálně potřeba pro 
určení typu stezky. Pokud se ukáže, že je to málo, můžeme navrhnout 
rozšíření. Ale pokud možno celosvětově uplatnitelné.





Marián



"







Honza




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

Re: [Talk-it] utilizzo ford=yes su piccoli torrenti/ruscelli asciutti (o quasi)

2016-06-09 Diskussionsfäden Max1234Ita

+2 (overo +1 ad entrambi i post precedenti)  :-)

/ford=yes/ indica semplicemente che lì *ci può essere acqua*. 
Che poi ci sia sempre, in inverno o solo dopo un temporale, poco importa, è
segnalato... e se sei in giro a piedi oppure in bicicletta, sapere che lì
potresti trovare un attraversamento difficoltoso ti è utile, se non hai
alternative a quel passaggio, quantomeno ci vai "preparato".

Ciao!
Max



--
View this message in context: 
http://gis.19327.n5.nabble.com/utilizzo-ford-yes-su-piccoli-torrenti-ruscelli-asciutti-o-quasi-tp5875065p5875075.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-de] Verwendung von Markenlogos in Karten?

2016-06-09 Diskussionsfäden Sven Geggus

markus schnalke  wrote:

> Symbole haben gerade den Vorteil, dass sie moeglichst weitreichend
> verstaendlich sind. Diese ``globale'' Verstaendlichkeit gegen eine
> evtl. bessere lokale Verstaendlichkeit zu tauschen, sollte im
> Einzelfall abgewaegt und nur bei deutlicher Verbesserung umgesetzt
> werden.

Das derzeitige carto-css Apothekensymbol kapiert kein Mensch.

https://github.com/gravitystorm/openstreetmap-carto/blob/master/symbols/pharmacy.16.svg

Das soll wohl eine Flasche oder Pillendose darstellen.

Ich tendiere dazu stattdessen das grüne Kreuz zu verwenden.

Sven

-- 
Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety (Benjamin Franklin)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-cz] kct_neco=neco [was: Re: Cykloznačení - puntík se stříškou]

2016-06-09 Diskussionsfäden Jan Breuer

Dne 9. června 2016 11:29 Marián Kyral  napsal(a):

> Dotaz.
>
> Jak na papírové mapě poznáš, co to je za trasa? Že to je zrovna odbočka k
> pramenu? Vetšinou podle značky ne? A pak podle legendy. A tu legendu můžeš
> připravit na základě route=* a osmc:symbol=*.
>
>
> Nemapujeme přeci pro renderer, ne? Aktuálně to má asi skoro nulové
využití, ale když už teď tu informaci máme, tak mě přijde škoda ji zahodit.
Spoléhat na osmc:symbol prostě nejde vždy - viz vlákno puntík se stříškou.

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

Re: [Talk-cz] kct_neco=neco [was: Re: Cykloznačení - puntík se stříškou]

2016-06-09 Diskussionsfäden Karel Volný

zdar,

> > > Viz téma weekly 301 - http://www.weeklyosm.eu/cz/archives/7383
> >
> > nepochopil jsem body 5 a 6
> >
> > dále nerozumím, co má hodnota tagu route společného s tím hiking
>
> Co je nesrozumitelného na relaci type=route; route=hiking? Jen se ptám, není 
> mě jasné, kde je v tom chyba.

na tom není nesrozumitelného nic (možná bylo nesrozumitelné mé vyjádření, co 
nechápu, neb nerozlišuje mezi hodnotou a klíčem), ale příslušný bod jde dál a 
praví:

6) zbylé value hodnoty současného tagu kct_barva “horse | ski | bicycle | 
wheelchair” lze spolu se souhrnným tagem “hiking” pro typy tras uvedené v 
předchozím bodu definovat v souladu s logikou i konvencí pomocí “nadřazeného” 
tagu route=*

to nechápu ... jak lze horse atd. definovat 'pomocí "nadřazeného" tagu route=*' 
jestliže tento už má hodnotu route=hiking?

> > dále navržené schéma samo porušuje bod 3, navíc o něm obdobně platí výtka,
> > kterou jsem měl v minulém mailu, že to nedává intuitivně smysl
>
> type=route
> route=hiking
> hiking=learning
> je jen logickým vyústěním zavedeného schématu, byť v posledním bodě zatím 
> nestandardní.
>
> Bohužel se tu duplikuje stejný seznam hodnot pro všechny klíče hiking, ski, 
> bicycle, wheelchair... což je asi to, na co narážíš?

ne tak úplně - narážím na to, že hodnota je vyjádřena přímo názvem klíče, což 
je v tom bodě 3 kritizováno

navíc to není konzistentní s aktuálním užitím těchto klíčů, to je definováno 
jako access

takže máme např. horse=yes, horse=designated ... jak do toho zapadne 
horse=learning a co z toho pochopí "náhodný čtenář"?

> Ideální by bylo zavést tag, nezávislý na způsobu přepravy,
> nezávislý na barvě a nezávislý na operátoru - tedy bez
> velkého přemýšlení něco jako route:purpose=learning?
> Znásilnění tagu network se stejným účelem by mělo
> příliš mnoho vedlejších efektů.

souhlas, tag určující účel trasy v tomto smyslu by měl stát stranou

a já bych šel ještě kousek dál, podle mého by se měl dát aplikovat na 
jednotlivé cesty v relaci, pořád si myslím, že by "ocásky" měly být součástí 
trasy, na kterou jsou napojeny (popř. tedy řešit to ne na úrovni cest, ale 
relace relací, třeba)

> Tady musím souhlasit s Karlem, osmc:symbol by podle
> mě měl nést informaci pouze o symbolu. Bohužel stále
> máme pocit, že kčt je jediný, kdo tvoří trasy. Pak ale
> někdo (ne-kčt) vytvoří trasu a dá ji značky úplně podle
> sebe. Musíme tedy mít schema, které jednoznačně
> definuje odbočku k prameni pro lyžaře, i když je
> značená růžovým srdíčkem na fialovém podkladě.

souhlas, napsal jsi to lépe než já

- bral jsem to z hlediska jeden symbol pro více významů, ale ono je to problém 
i naopak, více symbolů pro jeden význam ... prostě druh trasy a použité značky 
jsou dvě různé věci

například s tím horse, my máme puntík, a na OSM wiki je jako ilustrační obrázek 
route=horse bílá podkova na modrém podkladu

K.

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

[Talk-GB] RFC: Semi Automatic Import of schools

2016-06-09 Diskussionsfäden Christian Ledermann

Hi all,

I'd like to propose to use http://schools.mapthe.uk for a semi automatic import
of Ordonance Survey Open School grounds data combined with
edubase and seed data into OpenStreetMap.

The Tool is available at http://schools.mapthe.uk/
The sourcecode and documentation is available at
https://github.com/cleder/os-opendata-edubase

My tests with this tool are very encouraging, I'd like to go forward
to the imports
mailing list with this proposal.

-- 
Best Regards,

Christian Ledermann

Newark-on-Trent - UK
Mobile : +44 7474997517

https://uk.linkedin.com/in/christianledermann
https://github.com/cleder/


<*)))>{

If you save the living environment, the biodiversity that we have left,
you will also automatically save the physical environment, too. But If
you only save the physical environment, you will ultimately lose both.

1) Don’t drive species to extinction

2) Don’t destroy a habitat that species rely on.

3) Don’t change the climate in ways that will result in the above.

}<(((*>

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

Re: [Talk-cz] Cykloznačení - puntík se stříškou

2016-06-09 Diskussionsfäden Petr Holub

> NAVRZENE SCEMA NEROZBIJE MTBMAP
> 
> z nekolika duvodu:
> 1) s autorem MTBmap jsme navrh noveho schematu diskutovali
> 2) MTBmap neni vubec zavisla na kct_barva=* a kontroluje tuto hodnotu jen 
> tam, kde neni
> osmc:symbol
> 3) jakakoliv "hromadna akce" ve zmene tagovani by nebyla provedena bez 
> konzultace minimalne s
> Martinem Tesarem (MTBmap) a Petrem Vejsadou (poloha.net), tedy temi, kdo 
> vytvareji "primarni"
> zdroje (rendery) sledujici a espektujici realny stav znacenych tras v CR

OK - zejmena bod 3. Protoze vim, ze Martin na to moc casu ted nema
(bavili jsme se o nekolika trivialnich upravach smerem k osmc:symbol
a ani na ty nebyl cas).

Dik,
Petr


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

Re: [Talk-de] Verwendung von Markenlogos in Karten?

2016-06-09 Diskussionsfäden markus schnalke

[2016-06-08 14:33] Sven Geggus 
> 
> An einigen Stellen wäre es nun sicher schön Markenlogos in der Karte zu
> verwenden.

Man sollte allerdings aufpassen, dass die Verstaendlichkeit nicht
darunter leidet. Auch wenn es hier um den deutschen Kartenstil geht,
so bekommen diesen auch mal Fremde zu Gesicht und die koennen mit
einem DB-Logo sicher weniger anfangen als z.B. mit einer kleinen
Lokomotive.

Symbole haben gerade den Vorteil, dass sie moeglichst weitreichend
verstaendlich sind. Diese ``globale'' Verstaendlichkeit gegen eine
evtl. bessere lokale Verstaendlichkeit zu tauschen, sollte im
Einzelfall abgewaegt und nur bei deutlicher Verbesserung umgesetzt
werden. Andernfalls waere es nur Eye-candy ... und gleichermassen
usabilityhemmend.


meillo

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

Re: [Talk-es] Dudas sobre el mapa

2016-06-09 Diskussionsfäden Jorge Sanz Sanfructuoso

Hola.
Si hay grupo de telegram. Añademe al telegram y te meto en el grupo. soy
@Sanchi en Telegram.

un saludo.

El mié., 8 jun. 2016 a las 18:29, Noel Torres ()
escribió:

> Miguel Sevilla-Callejo  escribió:
>
> > Hola,
> >
> > Estuve echando un vistazo rápido y aunque a primera vista parecía que
> > alguien se hubiera cargado los límites del Sahara Occidental la relación
> > con los mismos sigue en la base de datos:
> > http://www.openstreetmap.org/relation/2559126
> >
> > Respecto a lo de Gibraltar supongo que esas son "sus" aguas
> territoriales y
> > en la base de datos se ha incluido que no estan reconocidas por España
> (de
> > hecho vi que la primera edición de estas con de @ivansanchez):
> > http://www.openstreetmap.org/way/345004359
> >
> > Otros asunto es si ha habido cambios recientes en ambas informaciones y/o
> > el render haya cambiado su aspecto.
> >
> > Recuerda que lo importante es que los datos (y por tanto la información
> de
> > la base de datos) estén correctamente etiquetados.
> >
> > ¿Algún avezado con las relaciones de límites internacionales para echar
> una
> > mano? Si no siempre se puede comentar a nivel de la lista internacional
> de
> > OSM.
> >
> > Un saludo
> >
> > --
> > *Miguel Sevilla-Callejo*
>
> Gracias
>
> ¿Hay grupo de Telegram para OSM actualmente?
>
> Noel
> er Envite
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
-- 
Jorge Sanz Sanfructuoso - Sanchi
Blog http://blog.jorgesanzs.com/
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-cz] kct_neco=neco [was: Re: Cykloznačení - puntík se stříškou]

2016-06-09 Diskussionsfäden Marián Kyral



-- Původní zpráva --
Od: Karel Volný 
Komu: OpenStreetMap Czech Republic 
Datum: 8. 6. 2016 16:44:22
Předmět: Re: [Talk-cz] kct_neco=neco [was: Re: Cykloznačení - puntík se 
stříškou]

"
> Ta významná informace o typu trasy se v té tvé tabulce přece mapuje 1:1 na
> osmc:symbol=*

myslímže tady mohu jedině zopakovat, co jsem napsal předtím:

"konkrétní příklad viz začátek tohoto vlákna: jak z red_dot poznám, jestli 
je 
to značka, na kterou ses původně ptal, anebo koňská stezka?"

- ano, čistě formálně v té "mojí" (ehm!) tabulce je sice mapování 1:1, ale 
ta 
taky nepostihuje všechny případy (a což teprv když je osmc:symbol=none), 
takže 
takováto odpověď je asi jako v tom vtipu "haló pane, prosímvás my se v té 
mlze 
ztratili, můžete nám říci, kde jsme? - jste v balóně" - formálně pravda, 
prakticky ... no ...
"



Dotaz.

Jak na papírové mapě poznáš, co to je za trasa? Že to je zrovna odbočka k 
pramenu? Vetšinou podle značky ne? A pak podle legendy. A tu legendu můžeš 
připravit na základě route=* a osmc:symbol=*.





Podle mně kombinace route=* a osmc:symbol=* stačí na určení zda se jedná o 
pěší, cyklo, koňskou, naučnou stezku nebo odbočku ke zřícenině.

Pokud by se vyskytl problém s identifikací, bylo by asi lepší shodnout se na
nové, více popisné značce jako třeba route:type (nebo něco lepšího). U té by
se případně dalo prosadit celosvětové používání.





Marián




"
K.___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz;___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-it] utilizzo ford=yes su piccoli torrenti/ruscelli asciutti (o quasi)

2016-06-09 Diskussionsfäden Andrea Albani

> a) si mette comunque sempre ford=yes
> b) si mette soltanto quando il punto di incrocio risulta almeno normalmente
> "bagnato"
> c) non si mette mai
>
> in altre parole ford=yes và soltanto messo dove effettivamente "ci si bagna
> le scarpe"?
>
>
Sapere se c'è presenza di acqua o meno deriva dall'eventuale tag
intermittent perchè Il tag ford=yes dice solo che c'è un passaggio.
Quindi io sono per la a).. che per altro come piacevole effetto collaterale
ti evita il warning del validatore di JOSM in salvataggio :)
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] utilizzo ford=yes su piccoli torrenti/ruscelli asciutti (o quasi)

2016-06-09 Diskussionsfäden Marco_T

demon.box wrote
> in altre parole ford=yes và soltanto messo dove effettivamente "ci si
> bagna le scarpe"?

Ciao Enrico,
io mi atterrei ai wiki ovvero ford=yes si mette quando un corso d'acqua
passa sopra una highway.
Considerato che non ci sono ulteriori specifiche io lo metterei sempre,
indipendentemente dal fatto che ci sia acqua o meno. In questo modo si
prevede la situazione peggiore e si segnala che in quel punto ci potrebbe
essere una situazione particolare (depressione, sassi affioranti, terreno
dissestato, melma, sabbiemobili...).

-- 
Marco_T




--
View this message in context: 
http://gis.19327.n5.nabble.com/utilizzo-ford-yes-su-piccoli-torrenti-ruscelli-asciutti-o-quasi-tp5875065p5875068.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Wochennotiz Nr. 307 31.05.2016–06.06.2016

2016-06-09 Diskussionsfäden Wochennotizteam

Hallo,

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

http://blog.openstreetmap.de/blog/2016/06/wochennotiz-nr-307/

Viel Spaß beim Lesen!
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Wochennotiz Nr. 307 31.05.2016–06.06.2016

2016-06-09 Diskussionsfäden Wochennotizteam

Hallo,

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

http://blog.openstreetmap.de/blog/2016/06/wochennotiz-nr-307/

Viel Spaß beim Lesen!
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Verwendung von Markenlogos in Karten?

2016-06-09 Diskussionsfäden Michael Reichert

Hallo Gisbert,

Am 09.06.2016 um 09:44 schrieb gmbo:
> Rechtlich dürfte die Verwendung machbar sein, im Normalfall hieße das
> aber Anfrage beim Markenrechtinhaber auf eine Erlaubnis, die man
> warscheinlich bekäme, da sie in direktem Zusammenhang mit den
> Unternehmen steht und gleichzeitig kostenlose Reklame ist.

Bei der Wochenaufgabe Apotheken hat jemand damals im Vorfeld beim
Deutscher Apothekerverband, dem Inhaber der Bildmarke "Apotheken-A"
nachgefragt und eine Absage erhalten. Ich bezweifle daher, dass der
Deutscher Apothekerverband hier eine Erlaubnis erteilen würde (v.a. weil
die Tiles und der Kartenstil-Quellcode unter einer freien Lizenz stehen).

Wenn du mehr zur Bildmarke "Apotheken-A" wissen willst, suchst du
einfach mal nach "Deutscher Apothekerverband" als Markeninhaber unter
https://register.dpma.de/DPMAregister/marke/einsteiger

Viele Grüße

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Talk-at] Schulkurse und ähnliche Gelegenheitskurse von Linienbuslinien

Hallo nochmal,
> * Es ist eine Zweckentfremdung. Eine Buslinie hat keine Öffnungszeiten,
> höchstens Betriebszeiten, und welche nimmt man überhaupt dafür?
> 
> * Es gaukelt eine Präzision vor, die nicht existiert; die
> opening_hours-Syntax zwingt Dich, Uhrzeiten anzugeben, aber damit
> kopierst Du bereits Fahrplandaten in OSM und das kannst Du niemals
> aktuell halten (wer will das bei jedem Fahrplanwechsel prüfen?)

Ok, dann lasse ich das mit dem adden von o_h mal. 

> Wäre es nicht vielleicht eine bessere Idee, analog zum vereinzelt
> bereits für Nachtbuslinien verwendeten service=night, ein neues
> Service-Tag einzuführen für solche Gelegenheitskurse? Bei uns gibt es
> z.B. auch einen Bus, der nur zu Messezeiten fährt und eine Straßenbahn
> zum Freibad nur im Sommer.

Es wäre schon sinnvoll hier einen Tag zu haben. Hat wer Lust ein Proposal zu 
verfassen?
Vorerst lasse ich die operating hours da wo sie schon drin sind. Ich bilde mir 
ein mal irgendwo gelesen zu haben, dass man den opening_hours tag auch für 
Busse verwenden kann. Finde aber die Quelle nicht mehr ..?LGRobinD  
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

[Talk-it] utilizzo ford=yes su piccoli torrenti/ruscelli asciutti (o quasi)

2016-06-09 Diskussionsfäden demon.box

ciao scusate, vorrei tornare su questo argomento riepilogando le idee che già
sono uscite in discussioni
precedenti.


1 - tutti i piccoli torrenti, torrentelli e ruscelli presenti sulle CTR
(anche se poi nella realtà
sono più o meno visivamente evidenti perchè sono quasi sempre asciutti
soprattutto a quote basse) vanno comunque mappati o lasciati se esistono già
(non ero di questa idea inizialmente ma poi ragionando con voi alla fine mi
trovo pienamente d'accordo).
ovviamente se è il caso sul tag waterway si aggiunge intermittent=yes

2 - in considerazione del punto 1 qual'è il corretto utilizzo del tag ford
nel punto di incrocio tra il sentiero e questi torrentelli quasi sempre
asciutti?

a) si mette comunque sempre ford=yes
b) si mette soltanto quando il punto di incrocio risulta almeno normalmente
"bagnato"
c) non si mette mai

in altre parole ford=yes và soltanto messo dove effettivamente "ci si bagna
le scarpe"?

grazie

--enrico



--
View this message in context: 
http://gis.19327.n5.nabble.com/utilizzo-ford-yes-su-piccoli-torrenti-ruscelli-asciutti-o-quasi-tp5875065.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-cz] Cykloznačení - puntík se stříškou

ahoj,
odpovim sireji v jinem mailu
zde jen reakce na Petrovu poznamku

NAVRZENE SCEMA NEROZBIJE MTBMAP

z nekolika duvodu:
1) s autorem MTBmap jsme navrh noveho schematu diskutovali
2) MTBmap neni vubec zavisla na kct_barva=* a kontroluje tuto hodnotu jen 
tam, kde neni osmc:symbol
3) jakakoliv "hromadna akce" ve zmene tagovani by nebyla provedena bez 
konzultace minimalne s Martinem Tesarem (MTBmap) a Petrem Vejsadou (poloha.
net), tedy temi, kdo vytvareji "primarni" zdroje (rendery) sledujici a 
espektujici realny stav znacenych tras v CR

OK?

vop


-- Původní zpráva --
Od: Petr Holub 
Komu: 'OpenStreetMap Czech Republic' 
Datum: 9. 6. 2016 6:58:29
Předmět: Re: [Talk-cz] Cykloznačení - puntík se stříškou

"Ahoj,

> Tak já z toho všeho nabyl pocit, že by se značka kct_* měla označit jako 
zastaralá, na nové
> trasy ji nedávat a ze starých ji postupně mazat.
> Co takhle umístit na osm.cz nějaké hlasování?

minimalne tim rozbijete MTBmap.cz - na nejakou dobu. V soucasne
dobe nikdo nema ji kapacitu zasadneji aktualizovat.

Petr


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

Re: [Talk-de] Verwendung von Markenlogos in Karten?

2016-06-09 Diskussionsfäden gmbo


Am 09.06.2016 um 01:43 schrieb Martin Koppenhoefer:


sent from a phone


Il giorno 08 giu 2016, alle ore 16:33, Sven Geggus 
 ha scritto:

An einigen Stellen wäre es nun sicher schön Markenlogos in der Karte zu
verwenden.

Typisches Anwendungsbeispiel wären große Supermarktketten aber auch das
gängige deutsche Apothekenlogo und das Logo der deutschen Bahn.


vom rechtlichen Aspekt abgesehen würde ich das nicht bei Firmen wie z.B. 
Supermärkten, Fast food Ketten oder Tankstellen machen, weil man die dadurch 
hervorhebt und gleich die Frage mitschwingt, warum man es beim kleinen Tante 
Emma Laden nicht macht (oder würdest Du es prinzipiell für alle machen wollen?).

Bei deutschen Apotheken fände ich das rote A gut, aber im Ausland (auf der dt. 
Karte) wiederum unpassend, ähnlich sehe ich es auch für S+U Bahnen, etc. Das DB 
Logo wäre auch nur für deutsche Bahnhöfe sinnvoll, im Ausland oder bei 
Bahnhöfen von anderen Betreibern nicht.
Bei den Apotheken ließe sich das schon machen, Da könnte die 
Landesgrenze das Logo wechseln. International wäre da dann das grüne 
Kreuz, welches aber auch bei uns vorkommt. Da gibt es ja nur wenige 
Länder 
(https://de.wikipedia.org/wiki/Apotheke#Apothekensymbole_in_verschiedenen_L.C3.A4ndern) 
in denen es andere Symbole gibt.
Bei Bahnhöfen wäre das schon schwieriger. Wenn ich mir da die 
railway=station ansehe, würde der oerator "DB Station & Service AG" zwar 
recht häufig da sein, aber viele Bereiche hätten dann keine ins Auge 
fallenden Bahnhöfe, Und ich weiß nicht was auf uns zukommt, wenn die 
Mitbewerber mit dem falschen oder fehlenden Logo klagen. Und wenn ich 
mir den Bereich Aachen - Köln - Koblenz ansehe habe ich viele Mitbewerber.


Bei den Handelsketten gibt es mit Sicherheit auch Probleme. Da hatte ich 
auch mal dran gedacht, aber wenn ich allein Aldi und Netto sehe wird es 
kompliziert. Ladesgrenze funktioniert bei Aldi/Hoffer aber die Grenze 
Nord/Süd ist schn nicht klar in den Daten.
Bei Netto wird es dann ganz kompliziert. Da gibt es inzwischen bei zwei 
völlig unterschiedliche konkurierende Ketten mit gleich getaggten Namen 
"Netto" zwei Lebensmitteldiscounter mit änlichem Sortiment in einer 
Stadt . Von den kleinen, die dann ja auch kein Logo haben mal abgesehen.


Ich würde daher lieber in einer Grundkarte gleiche Symbole sehen und die 
Logos eher in zusätzlichen Layern, dann eher eine etwas weitere 
Aufgliederung wegen des Sortiments, aber da ist das Tagging noch nicht 
so weit.


Rechtlich dürfte die Verwendung machbar sein, im Normalfall hieße das 
aber Anfrage beim Markenrechtinhaber auf eine Erlaubnis, die man 
warscheinlich bekäme, da sie in direktem Zusammenhang mit den 
Unternehmen steht und gleichzeitig kostenlose Reklame ist.


Gruß Gisbert


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

[OSM-talk] Last chance to help pick sessions for SotM

2016-06-09 Diskussionsfäden joost schouppe

Hi,

The SotM team is asking for your input to help pick sessions for SotM
Brussels. You can rate talks here :

http://tidean.made4it.com/250/index.php/387889?lang=en

Please do so before Friday night, as we will be closing the poll.

More info about this poll here:
https://blog.openstreetmap.org/2016/06/04/community-survey-for-the-state-of-the-map/
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-at] Schulkurse und ähnliche Gelegenheitskurse von Linienbuslinien

2016-06-09 Diskussionsfäden Frederik Ramm

Hallo,

On 06/09/2016 09:15 AM, Robin Däneke wrote:
> Ich werde jetzt beginnen den Linien in Wien pro Kurs opening_hours Tags
> zu verpassen. Hab ich ja bei ein paar Linien eh schon gemacht. Somit
> wäre es der Konsistenz wegen nur sinnvoll, das bei allen Linien zu
> machen .

Ich finde das mit den opening_hours keine so gute Idee, aus
verschiedenen Gründen:

* Es ist eine Zweckentfremdung. Eine Buslinie hat keine Öffnungszeiten,
höchstens Betriebszeiten, und welche nimmt man überhaupt dafür?

* Es gaukelt eine Präzision vor, die nicht existiert; die
opening_hours-Syntax zwingt Dich, Uhrzeiten anzugeben, aber damit
kopierst Du bereits Fahrplandaten in OSM und das kannst Du niemals
aktuell halten (wer will das bei jedem Fahrplanwechsel prüfen?)

* Es ist schwierig auszuwerten. Wenn ich eine Karte zeichne, dann
interessiert mich vielleicht die Unterscheidung, ob eine Linie selten,
häufig, oder nur nachts befahren wird, aber ich will nicht unbedingt dem
Renderer beibringen, wie man opening_hours parst (es *geht* in SQL, aber
...)

Wäre es nicht vielleicht eine bessere Idee, analog zum vereinzelt
bereits für Nachtbuslinien verwendeten service=night, ein neues
Service-Tag einzuführen für solche Gelegenheitskurse? Bei uns gibt es
z.B. auch einen Bus, der nur zu Messezeiten fährt und eine Straßenbahn
zum Freibad nur im Sommer.

Ein Kartenzeichner könnte dann überlegen: Richtet sich seine Karte an
Leute, die wissen wollen, wo die ÖPNV-"Verkehrsadern" sind (dann zeichne
ich nur die normalen, häufig befahrenen Kurse), oder soll die Karte
zeigen, wo grundsätzlich vielleicht irgendwann mal ein Bus vorbeikommt
(dann zeichne ich auch die Gelegenheitskurse).

Bye
Frederik

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

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

Re: [OSM-talk-fr] Liens Wikidata (Était : ERDF (et RFF) ont changé de nom)

2016-06-09 Diskussionsfäden François Lacombe

Tenez, ça va dans le bon sens : iD vient juste d'être mis a jour avec cette
fonctionnalité intéressante

https://twitter.com/bhousel/status/740567649894031369?s=09

François
Le 8 juin 2016 12:08 PM, "François Lacombe"  a
écrit :

> Bonjour Jean-Yvon,
>
> Le 8 juin 2016 à 03:03,  a écrit :
>
>>
>>
>>
>>
>> Le 2016-06-08 à 00:25, François Lacombe - fl.infosrese...@gmail.com a
>> écrit :
>>
>> Globalement on pourrait supprimer tous les noms propres de la base !
>>
>> Comme dit implicitement précédemment : non, la base OSM est bien plus
>> riche en termes de noms. *Pour les name:pays, tu as raison*.
>>
>
> Je pensais urbanisme, Wikidata proposant nativement la gestion des noms
> multiples et les rattachant à une notion commune (voire à plusieurs).
> Ce n'est pas parce qu'OSM est plus riche en noms que cette solution est
> adaptée. Vu l'embrouille avec les name:*, name_x, etc... wikidata challenge
> tout ça efficacement.
>
>
>> Mais tous *les short_name, old_name, alt_name n'ont pas d'équivalent
>> dans Wikidata* ou je dis une connerie ?
>>
>
> Les attributs dans wikidata sont figés par les admins, mais à géométrie
> variable tout de même (on peut demander à en créer).
> Il suffit d'en discuter avec eux.
>
>
>> Pour MLTVULCA merci pour les explications.
>> Tu veux dire qu'il manque un nom et un website sur le bâtiment au sud ;-).
>> Je suis allé regarder sur les vues de BigBrother, c'est un petit poste de
>> quartier, pas lié à 
>> http://www.mltvulca.com/presentation.htm
>>
> Comment le sais-tu ? Regarder sur streetview ne suffit pas.
> Le poste porte le nom d'une entreprise, c'est un client avec de fortes
> demande de puissance vu son activité. Le poste a de fortes chances d'être
> un poste de livraison privé en limite de propriété.
>
>
>> Car ce n'est pas un poste privé mais un poste pour cette boîte et
>> quelques maisons.
>>
> Comment en être si sûr ?
> Pour les postes privés (qui portent le plus souvent le nom du client), le
> distributeur ne peut pas raccorder de tiers dessus.
> Ce n'est pas parce que le poste prend l'apparence d'une cabine en bordure
> de domaine public qu'il y a forcément des maisons raccordées dessus.
>
>
>
>> Donc on devrait avoir un ref:ERDF:GDO (si ce ne me trompe) qui ne serait
>> pas MLTVULCA.
>>
> De tels codes ont un format bien particulier comme expliqué sur le wiki,
> MLTVULCA reste le nom d'usage du poste et jamais sa référence.
>
>
>> J'avais viré le name car ce n'est pas un nom. Si on considère que le
>> libellé doit être dans le champ name, je pense qu'il faut améliorer le wiki
>> sur ce point.
>>
>
> C'est le nom d'usage, donc on le met dans name=*.
>
>
>> Le wiki power=substation
>>  dit :
>> name   Le nom d'usage
>> du poste électrique recommandé
>> operator   Nom
>> de l'exploitant du poste électrique optionnel
>> ref   Identifiant
>> unique du poste électrique optionnel Trop vague. Pour moi la suite de
>> caractère est la référence sur un plan, pour Enedis sur la commune.
>> S'il y a un problème sur le poste, qu'on appelle Enedis je suppose que
>> s'il n'y a pas de GDO de lisible, on parle du poste de MLT Vulca ou on dit
>> qu'il y a écrit MLTVULCA. Le non d'usage c'est MLT Vulca.
>>
> Ok pour ça.
>
>
>> Si initialement j'avais supprimé le doublon nom/ref c'est qu'Osmose
>> braillait, à mon avis avec raison, contre ces noms TOUT EN MAJUSCULES.
>>
>> 
>> http://wiki.openstreetmap.org/w/images/b/b4/French_power_substation_code5d.jpeg
>> : son nom est à mon avis Viking, peut-être Viking 10829, pas VIKING ou
>> VIKING 10829.
>>
> Il n'y a pas de vérité dans le domaine, ce qui compte c'est ce qui est
> indiqué sur le terrain. Et en l'occurence il y a des majuscules.
> J'ai aussi tendance à remettre les noms en minuscules, mais ca se situe
> entre l'erreur manifeste et la vérité :)
>
> Dans le cas ou on voudrait conserver la vue terrain, ceci est valide :
> name=Viking
> ref=10829
> ref:ERDF:gdo=76540P10829
>
>
> Il va falloir revenir sur ce tag ref:ERDF:gdo parce que :
> il contient ERDF qui n'existe plus
> il ne contient pas FR alors qu'il ne concerne que la France et rien
> d'autre.
>
> ERDF c'est aussi un fond Européen qui peut financer des projets ayant une
> réalité sur terrain, avec des référence... risque de collision.
> On devrait profiter pour rendre ce tag plus conforme pendant qu'il n'y a
> que 1000 objets et que le wiki est relativement complet.
>
>
>>
>> C'est par contre dit assez clairement sur FR:Key:ref:ERDF:gdo
>>  qu'on prend le
>> nom tel quel... et qu'on utilise pas ref.
>>
>> C'est à dire que pour savoir remplir un

Re: [Talk-at] Schulkurse und ähnliche Gelegenheitskurse von Linienbuslinien

Hallo nochmal,
Ich werde jetzt beginnen den Linien in Wien pro Kurs opening_hours Tags zu 
verpassen. Hab ich ja bei ein paar Linien eh schon gemacht. Somit wäre es der 
Konsistenz wegen nur sinnvoll, das bei allen Linien zu machen .LG Robin D.
  ___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Schulkurse und ähnliche Gelegenheitskurse von Linienbuslinien

2016-06-09 Diskussionsfäden Stefan Tauner

On Thu, 9 Jun 2016 07:58:54 +0200
Christian Aigner  wrote:

> Das Problem ist nicht, daß der Kurs auf der Karte eingezeichnet ist, was
> ich für richtig halte, sondern die Erwartungshaltung der Benutzer der Karte.
> 
> Eine Landkarte ist kein Fahrplan. Eine Landkarte muß nicht die
> Häufigkeit, die Abfahrtszeiten usw. berücksichtigen.

Sie muss nicht, aber es wäre doch sehr sinnvoll, wenn die notwendigen
Informationen zur Unterscheidung der hochfrequent befahrenen Teile von
denen, die nur einmal pro Tag befahren werden, vorhanden sind und von
den Renderern auch interpretiert würden, um den Nutzern einen Hint zu
geben (z.B. farbliche Unterscheidung)... ich kann bis jetzt nämlich
keine technischen oder kartographischen Gegenargumente in diesem Thread
finden, außer "hots no nie gebm" und "die Nutzer sind halt zu blöd". :)

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

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

Re: [Talk-it] Buongiorno, sono un nuovo iscritto

2016-06-09 Diskussionsfäden Michele iw1gfv

Ciao Alessandro.
Potrebbe dipendere dal file TYP presente nella mappa, che non è routable, in 
pratica non è del tipo che permette la navigazione ed il calcolo 
dell'itinerario.
Prova a caricare un' altra mappa, sempre basata su osm, quasi di sicuro risolvi 
il problema.

Il 7 Giugno 2016 14:41:30 CEST, Alessandro Srr  ha 
scritto:
>Mi sto appassionando al mondo GPS e pertanto era impossibile non
>passare da queste parti 
>Ho 59 anni, sono un moto-viaggiatore (moto-turista non mi piace) e
>avevo intenzione di usare la mappa OSM generic router
>(italia-slovenia-croazia) affiancata alla ufficiale Garmin. Ho un mac
>sul quale ho installato BaseCamp 4.6.3. Nessun problema per aggiungere
>la mappa OSM generic routable ma, sorpresa sorpresa, BaseCamp con
>questa mappa calcola gli itinerari correttamente solo in modalità
>fuoristrada, pedonale, bici, ecc., ma se imposto alla guida, moto, moto
>panoramica ecc. (ovvero per utilizzare strade e non sentieri o
>similari) mi traccia solo una linea retta. Vorrei precisare che in
>passato, con altre versioni di BaseCamp e di mappe OSM, non ho mai
>avuto problemi di questo tipo. Non sono quindi in gradi di dire se si
>tratti idi un problema di BaseCamp o di mappa. Ci sono altri che hanno
>incontrato (si sono scontrati) con questo problema? Nel caso, come lo
>hanno risolto?
>Ringrazio anticipatamente chiunque sia disposto a darmi una mano e gli
>altri che hanno avuto la pazienza di leggermi.
>
>Alessandro   
>
>
>
>___
>Talk-it mailing list
>Talk-it@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-it

-- 
iw1gfv.it
piemontegps.altervista.org
badgersclub.org___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-at] Schulkurse und ähnliche Gelegenheitskurse von Linienbuslinien