Re: [OSM-talk] The Proposed Great Colour Shift
On Thu, Aug 20, 2015 at 3:16 AM, Jóhannes Birgir Jensson j...@betra.is wrote: Should this be a new, alternative style instead? IMHO for every user that likes the new scheme, you will find one that hates it. And vice versa. As someone that grew up with Falck and Michelin maps, it took a long time to understand why someone would come up with such a weird color scheme (the rainbow scheme you refer to). I had read somewhere that it was done because the ugly colours would force people to make their own maps. Only later I understood it was the common colour scheme in the UK. I guess we will never know what's the best way to proceed. Usually people that don't like the change are very vocal, the lovers not so much. And then there are many many people that do not speak out or do not care. FYI, the Britisch community is trying to set up their own tile server to preserve the rainbow colour scheme, at least for the British islands. regards m ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] YoHours version 2 disponible
Merci pour ce très bel outil. Une toute petite remarque : puisque l'outil est sur le web (comme beaucoup maintenant) pourquoi ne pas plutôt choisir la licence AGPL. Le A dit que même si seul le service est ouvert, le code d'une version dérivée doit AUSSI être partagé. C'est ce que vous cherchez me semblet-t-il ? Bonne journée et encore merci, Nicolas Le 2015-08-19 20:48, PanierAvide a écrit : Bonsoir, L'outil permettant de simplifier la saisie des horaires d'ouverture YoHours est disponible dans sa nouvelle version. Il est possible désormais de définir des horaires différentes selon les semaines, mois, périodes de vacances... C'est disponible ici : http://github.pavie.info/yohours/ D'autres nouveautés font également leur apparition : * Saisie directement dans l'interface par l'utilisateur d'une valeur opening_hours * Valeur affichée présente dans l'URL, permettant d'envoyer un lien pour un valeur donnée * Le calendrier s'affiche en entier sans double barre de défilement, et est plus condensé * Gestion des intervalles sur la nuit (par exemple de 23h à 3h du matin) * Une aide à l'utilisation * Un relooking du site pour avoir un design un peu plus sympa N'hésitez pas à me faire part de vos remarques, suggestions, ou rapports de bugs ;) Cordialement, PanierAvide. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Nicolas Pettiaux, phd - nico...@pettiaux.be Open@work - Une Société libre utilise des outils libres ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-es] CheckAutopista2
El 19 de agosto de 2015, 10:52, k1wi k1wi...@gmail.com escribió: Os animo a probarlo y comentarme que os parece. Comentarios breves y rápidos: * Incluso conociendo la versión anterior y sabiendo qué pretende la herramienta... he echado de menos tener tooltips o similar en cada botón/acción. Algunas no son evidentes viendo solamente el icono. * No hay muchos textos, pero sería genial si pudieras hacer la web multi-idioma. * Por algún motivo, supongo que relacionado con los datos, no me detecta la M-50... lo miraré luego desde casa Enhorabuena de nuevo, es una herramienta muy útil :-) -- Luis García ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-us] Tagging National Forests
On 08/19/2015 07:25 PM, stevea wrote: This isn't extreme. Your backyard activity is consistent with the definition of a forest: a land which is used for the production of wood/lumber/timber/firewood/pulp/et cetera. Frederik, Frederik, Frederik...where do I begin?! According to our wiki, which I DO follow when there is ambiguity or any question about what or whether I should map something, landuse=forest is used to mark areas of land managed for forestry. As I have said here before (recently), this is EXACTLY, PRECISELY what a USFS national forest is. If we change what tags mean in this project, we ought to have a better set of tags to use instead, and we are some distance from that. There is a problem with this definition; it is too broad. I use the wiki definition I note above. Consistently. Even on polygons from local zoning/cadastral data marked as Timber Production in my county. Whether there is active felling of trees or not. The heart of the matter here is quite likely that the wiki definition for forest is overloaded: OSM uses at least four different interpretations as the wiki outlines. A solution to this problem might start with consensus-based re-definition, followed by consistent (worldwide) application of the new method, and rendering support to see what we have done. That's a lot of work we ought to get started doing. Even the seabed can fulfil some of these uses and we don't want to tag forests in the sea. What the heck? I know of no trees growing on the seabed! (Although if there were an odd tree, say near the shoreline of the sea, I agree with a natural=tree node there -- but I don't think I've ever seen one). This definition of a forest is unsuitable for OSM and should not inform our tagging. (Luckily the Wiki, which is not always reliable on these issues, says: A forest or woodland is an area covered by trees., and not: A forest is an area where you could potentially find something to light a fire with.) Please don't twist what I say, conflate my meanings or read into what I have written, as it appears you have. What I have done is apply the wiki definition (area of land managed for forestry) to USFS polygons. Stick to that and tell me I'm wrong, because I don't believe I am by that definition and application. There is also a problem with your interpretation of this already-unsuitable definition; you say that if land yields wood for any reason, it is used in the production of wood. But I see a difference here between scavenging and agriculture. Just because there's wild berries somewhere, doesn't make the area an orchard. Just because you are legally allowed to pick up a branch that has fallen down from a tree, doesn't make this a lumber production facility. It's way off the rails confusing scavenging and agriculture (oh, and the US Forest Service is actually a unit of the Department of Agriculture -- as in, those trees are GROWN to be HARVESTED by US, its owners). I only used wood-gathering as proof that I use these lands as forest, ipso facto they should be tagged that way: landuse=forest. Do you have a problem with that? Let's stick to that, rather than seabeds and wild berries. Your definition is unsuitable, and your interpretation of your unsuitable definition is extreme, and it seems like you're fighting political battles/squabbles on the back of OSM. Whether something is a park or a national reserve should not be subject to your personal interpretation of your country's constitution. Hey, the politics of this is real: I am the owner of these lands (along with hundreds of millions of others), and I take offense that you call this political like I have a squabble to pick on the back of OSM. I don't: I tag OSM with the reality of these public lands as they are defined in our wiki. If you have a problem with that, perhaps you might update the wiki (but please, let's achieve consensus first). Your definition is unsuitable and your interpretation of your unsuitable definition is extreme... Wow, Frederik, those are pretty harsh words to a passionate volunteer like me (a top 50 US contributor), a speaker at our national conferences, present and active for most of the history of this project, responsible for over 10,000 quality edits and somebody who is honestly and truly dedicated to doing the right thing. Are you looking to alienate me from this project? Because words like yours above go a long way towards doing exactly that. Do you mean to do so? To me, a lot of your bordering-on-political-rant argument reads like what we get in other areas of the world where people fight over control of areas; and we tell them: We map the reality on the ground, not some wishful thinking. You might see yourself as the (co)-owner of everything controlled by the US government but if they decide to put up a law, a fence, or a guard keeping you from enjoying what is yours then please take it up with
Re: [OSM-talk-fr] YoHours version 2 disponible
Peux-tu ajouter un paramètre sur la précision du pas de temps? Genre 15min, 30min, 1h Le 20 août 2015 11:47, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Oups, erreur de test sur 15min désolé... En effet, la factorisation est bien prise en compte. ;-) Merci encore pour cet outil. Le 20 août 2015 11:33, panierav...@riseup.net a écrit : Bonjour, La plupart des factorisations possibles sont déjà mises en place. Quels sont les éléments qui te semblent encore factorisables ? Cordialement. Le 2015-08-20 11:25, Jérôme Seigneuret a écrit : Bonjour, Une factorisation de la chaîne pourrait être intéressante pour ne pas avoir une ligne trop longue. Jérôme ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] The Proposed Great Colour Shift
What you are proposing is basically design by committee
(https://en.wikipedia.org/wiki/Design_by_committee) which is rampant
everywhere in OSM and kills innovation. Everyone wants to pile on their
own cause - be it privacy (see the latest pull request on Github
regarding Gravatar for another viable contender for the Waste of Time
prize) or some weird anarchy/freedom/whatever world views.
At the same time there's a guy (Mateusz) who took on the task of making
the default style not suck - so what do people here do? Of course, let's
discuss this to death until everyone agrees. But then you may find that
no one wants to work with you on this anymore.
In Poland we have this often-used saying with regards to the political
or social situation (yeah, we Poles like to complain a lot!) - it sucks
but at least it's stable!
Paweł
On Thu, Aug 20, 2015, at 11:39, Colin Smale wrote:
That discussion is only a waste of time because people hope that a consensus
will magically appear. The subject of the discussion is absolutely something
which deserves air-time. I am not talking about the specific case of
abandoned railways, but about who has the right to decide what data has no
place in OSM and order its deletion.
What was that famous line in Animal Farm again?
--colin
On 2015-08-20 10:53, Paweł Paprota wrote:
I'm taking bets on whether this thread will have more replies than the
abandoned railroads (100+ and still going strong!) and win the prize
for the Biggest Waste of Time in OSM for 2015.
YES WE CAN('T)
Paweł
On Thu, Aug 20, 2015, at 03:16, Jóhannes Birgir Jensson wrote:
For those that did not check on Mateusz Konieczny diary
entries[1[http://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/35586]],
postings to this mailing list and github discussions then the Proposed
Great Colour Shift might come as a surprise if it is implemented.
According to the github discussion there is an overwhelming consensus
[2] on moving from current rainbow colour scheme for roads to a
red-yellow only scheme. I am unsure of where this overwhelming consensus
formed because I never saw it on this mailing list nor on talk-dev nor
on announcements, I admit to be an infrequent IRC user but I didn't see
this overwhelming consensus there and so far no one has been able to
tell me where it formed or where I can find it.
The design goal seems straight forward, to discontinue green and blue
for roads and move to red and reddish. For this to happen the decision
was made to shift current primary, secondary and tertiary colours
upwards so primary is now the colour of secondary and secondary the
colour of tertiary. Leaving tertiary white.
Tertiary instead gets to be wider than residential and unclassified
roads, but to be able to spot that you need to have it next to them to
see which is the wider one.
This one simple change of bleaching tertiary however is something I find
to be a great hindrance to mapping efforts, particularly in rural areas
where the roads are isolated and panning over the map, wether in iD or
using default tiles. Currently it is easy to spot tertiary roads snaking
through valleys and over vast desert plains, they are yellow and the non
tertiary roads are white. Tertiary is significant there as it denotes
the roads between the villages and towns that are often unpaved but
still the most important, even the only, road. Lesser white colours
imply the roads not being between larger settlements although they could
lead to hamlets. The guidelines for mapping in Africa state thus.
Removing the colour from tertiary makes all mapping that much harder to
verify and quality check. Currently it is easy to see if a tertiary road
is broken with a white unclassified bridge, not so in the proposed Great
Colour Shift.
Mateusz has been forthcoming with all changes and done sterling work in
displaying different areas and how they will look. But he acknowledges
that this change is not beneficial everywhere on the map and now has a
disclaimer:
Among potential problems are that it is now harder to recognise road
type of given road, especially in situation where there is no
possibility to compare it with other road types.
Such significant change will be confusing for current users of this
style.
UK color coding of roads is well known for many people, for them a new
style - even assuming that it would be intuitive for them - will be less
useful.)
The question really arises if this change is beneficial or not for the
project. Many hours have gone into it and doing CartoCSS on all these
zoom levels is not trivial. But this is a major shift on the front page
of our website, a blow to those who use the default tiles through uMap
or similarly and depend on the UK rainbow road style and makes life
harder for mappers to visually confirm the type of road.
Re: [Talk-at] Graz+Innsbruck: »Schiene und Straße wurden getrennt«
Hallo Jonathan, ich hab eben ein Changeset von dir gesehen: https://overpass-api.de/achavi/?changeset=33438887 Abgesehen davon, dass du bitte den Ausgang der Diskussion auf der Mailingliste - oder zumindest den nächsten Grazer Stammtisch - abwarten solltest, bis du mit der Aktion weitermachst, war das Changeset so voller Fehler, dass ich es eben reverted habe: • doppelte Ways (Geometrien überlappend) • Tags unkorrekt übertragen Sag mal, bist du eigentlich aus Graz? Dann bitte komm zum Stammtisch nächste Woche Montag! Wir haben hier in Graz eine gut funktionierende OSM-Community - ich mag es garnicht, wenn Leute remote ohne sich mit den lokalen Mappern abzusprechen bei unseren Daten herumpfuschen. Danke, lg Michael -- Michael Maier, Student of Telematics @ Graz University of Technology OpenStreetMap Graz http://osm.org/go/0Iz@paV http://wiki.osm.org/Graz http://wiki.osm.org/Graz/Stammtisch signature.asc Description: OpenPGP digital signature ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] YoHours version 2 disponible
C'est vraiment super !! Perso. j'aimerais bien : * Du français * Que la barre du haut reste toujours visible ou que l'ensemble tienne sur une seule page Le 20/08/2015 00:36, Florian LAINEZ a écrit : Bravo Adrien, c'est superbe ! IL ne manque en effet qu'une intégration à ID pour que cela soit pleinement utilisable ;) Le 19 août 2015 22:57, Philippe Verdy verd...@wanadoo.fr mailto:verd...@wanadoo.fr a écrit : en passant je note les fetes mobiles avec pâques qui tombe toujours un dilanche mais pas les autres dates calculees avec un nombre fixe de jours avant ou apres paques. de plus ce n'est pas clair qu'il s'agit de la paques occidentale ou orientale calculee sur le calendrier julien orthodoxe. il faudrait ajouter un champ avec un nombre fixe de jours. bien qu'en france seule la paques occidentale est utilisee, ce n'est pas forcement vrai pour les services liees aux confessions orthodoxes ou juives. pour les musulmans il faudrait aussi les dates des fetes de l'haïde (pas sur de l'orthographe) sachant qu'il est probable qu'il y ait leur i troduction a mayotte ou la reunion. Le 19 août 2015 21:05, frem mjnpodq.f...@harmon.fr mailto:mjnpodq.f...@harmon.fr a écrit : Le 19/08/2015 20:48, PanierAvide a écrit : L'outil permettant de simplifier la saisie des horaires d'ouverture YoHours est disponible dans sa nouvelle version. Il est possible désormais de définir des horaires différentes selon les semaines, mois, périodes de vacances... C'est disponible ici : http://github.pavie.info/yohours/ Bravo, c’est un super travail. Je l’ai utilisé la semaine dernière pour mettre à jour les horaires de commerces proches de chez-moi et c’était déjà extrêmement pratique. :-) Je pense que c’est le genre d’outil qui peut démocratiser la contribution à OSM, pour des données aisément compréhensible et utiles à tt le monde. Penses-tu que ce serait intégrable à iD ? -- Contributeur OSM (frem-eu). Retrouvez aussi une partie des contributeurs OpenStreetMap de la Vienne aux permanences de l’APP3L (app3l.org http://app3l.org). ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- http://lovielhcasse.lautre.net/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-us] Tagging National Forests
Hi, On 08/19/2015 07:25 PM, stevea wrote: This isn't extreme. Your backyard activity is consistent with the definition of a forest: a land which is used for the production of wood/lumber/timber/firewood/pulp/et cetera. There is a problem with this definition; it is too broad. Even the seabed can fulfil some of these uses and we don't want to tag forests in the sea. This definition of a forest is unsuitable for OSM and should not inform our tagging. (Luckily the Wiki, which is not always reliable on these issues, says: A forest or woodland is an area covered by trees., and not: A forest is an area where you could potentially find something to light a fire with.) There is also a problem with your interpretation of this already-unsuitable definition; you say that if land yields wood for any reason, it is used in the production of wood. But I see a difference here between scavenging and agriculture. Just because there's wild berries somewhere, doesn't make the area an orchard. Just because you are legally allowed to pick up a branch that has fallen down from a tree, doesn't make this a lumber production facility. Your definition is unsuitable, and your interpretation of your unsuitable definition is extreme, and it seems like you're fighting political battles/squabbles on the back of OSM. Whether something is a park or a national reserve should not be subject to your personal interpretation of your country's constitution. To me, a lot of your bordering-on-political-rant argument reads like what we get in other areas of the world where people fight over control of areas; and we tell them: We map the reality on the ground, not some wishful thinking. You might see yourself as the (co)-owner of everything controlled by the US government but if they decide to put up a law, a fence, or a guard keeping you from enjoying what is yours then please take it up with them and don't use OSM to map what you would like reality to be. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk-fr] YoHours version 2 disponible
Bonjour, Une factorisation de la chaîne pourrait être intéressante pour ne pas avoir une ligne trop longue. Jérôme Le 20 août 2015 11:09, Donat ROBAUX dona...@gmail.com a écrit : Merci Adrien pour cette nouvelle version. Est-il possible d'avoir la tirette de descente sur les horaires également en horizontal? Ex: ouverture L-V 8h-12h. On met l'horaire 8h-12h sur le lundi et en tirant sur les autres jours, ca recopie 8h-12h Donat ___ 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] Paths and Footways
Hi, FWIW I have developed an app (OpenTrail) which provides offline maps for UK walkers (actually only England for now) showing ROWs in the same colour scheme as Freemap, using Mapsforge. The designation tag is used to render the footpaths It's not necessarily slick enough to be an official OSM UK app but could be used as a basis to develop something (by myself if necessary if someone had a list of requirements) It's available at http://www.free-map.org.uk/common/opentrail.html and source https://github.com/nickw1/Freemap (the 0.1 version is older but more stable) The big PITA at the moment is the need to generate MAP files from OSM data which I have to do annually however I am working on modifying mapsforge to optionally use a geojson web service instead, allowing dynamic updates on demand. Nick From: Dudley Ibbett dudleyibb...@hotmail.com Sent: 18 August 2015 21:16 To: Rob Nickerson; talk-gb@openstreetmap.org Subject: Re: [Talk-GB] Paths and Footways Hi Rob My approach is a pragmatic one. I've come to the conclusion that it isn't reasonable to expect the default OSM website to render the specialist features that a UK walker would want. The gold standard for UK walkers has to be the OS 1:25 so you would need contours, the British National Grid, public rights of way etc.To be honest, even with these additional features we lack the basic data in many parts of the UK to provide the coverage needed for an alternative to the 1:25. It does however appear that where the data is reasonable we are being used. The following provides an example of a definite map overlay. http://www.derbyshire.gov.uk/leisure/countryside/access/rights_of_way/rights_of_way_network/default.asp#14/53.1728/-1.6869 Presumably this is a vector overlay of the type being referred to and perhaps this could be one way forward. I guess we could do something like this using the designation tag. I believe the UK public right of way access is rather unique in the way it gives access through farmland, farmyards, residential properties etc. I find it quite bizarre at times that you can end up walking through someone's garden quite legally. I does potentially provide some unique rendering issues in the UK as a consequence. In the field, most walkers will actually use an offline map and wouldn't want to rely on internet access and the OSM website. I guess OSMand with a suitably rendered UK vector map would be the alternative. Kind Regards Dudley Date: Mon, 17 Aug 2015 23:25:35 +0100 From: rob.j.nicker...@gmail.com To: talk-gb@openstreetmap.org Subject: Re: [Talk-GB] Paths and Footways Thanks Andy, Fully aware of access land, undocumented rights of way and permissive paths. I just need to remember to be careful of what I write on this mailing list (but I was trying not to write an essay). I'm surprised if this is just England and Wales as I would have thought some other country has some way of documenting paths in a legal context and as such this may be relevant for other countries, but the real question is: would having some way to show the importance of particular paths/footways (just like roads have a classification) help, and if yes, how should we do this? So far there is little interest to do this on the OSM default render style which seems odd to me given how much fuss there has been on this list to recent changes to the footway/path style (over the last year)! Rob ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk-fr] YoHours version 2 disponible
Excellente remarque, je ne connaissais pas cette licence, mais c'est vrai qu'elle se prête mieux aux services web tout en respectant les principes de la GPL. Je vais changer ça, merci :) Le 2015-08-20 10:44, Nicolas Pettiaux a écrit : Merci pour ce très bel outil. Une toute petite remarque : puisque l'outil est sur le web (comme beaucoup maintenant) pourquoi ne pas plutôt choisir la licence AGPL. Le A dit que même si seul le service est ouvert, le code d'une version dérivée doit AUSSI être partagé. C'est ce que vous cherchez me semblet-t-il ? Bonne journée et encore merci, Nicolas ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] stop deleting abandoned railroads
sent from a phone Am 19.08.2015 um 20:06 schrieb Glenn Powers gl...@net127.com: For the record, I deleted an abandoned railway that leads through a new housing development, because it didn't make any sense to leave it there. Satellite images clearly show ground gradings indicating an abandoned railway. What was the situation on the ground? Were you able to take some photos? Cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The Proposed Great Colour Shift
That discussion is only a waste of time because people hope that a
consensus will magically appear. The subject of the discussion is
absolutely something which deserves air-time. I am not talking about the
specific case of abandoned railways, but about who has the right to
decide what data has no place in OSM and order its deletion.
What was that famous line in Animal Farm again?
--colin
On 2015-08-20 10:53, Paweł Paprota wrote:
I'm taking bets on whether this thread will have more replies than the
abandoned railroads (100+ and still going strong!) and win the prize
for the Biggest Waste of Time in OSM for 2015.
YES WE CAN('T)
Paweł
On Thu, Aug 20, 2015, at 03:16, Jóhannes Birgir Jensson wrote:
For those that did not check on Mateusz Konieczny diary entries[1 [1]],
postings to this mailing list and github discussions then the Proposed
Great Colour Shift might come as a surprise if it is implemented.
According to the github discussion there is an overwhelming consensus
[2] on moving from current rainbow colour scheme for roads to a
red-yellow only scheme. I am unsure of where this overwhelming consensus
formed because I never saw it on this mailing list nor on talk-dev nor
on announcements, I admit to be an infrequent IRC user but I didn't see
this overwhelming consensus there and so far no one has been able to
tell me where it formed or where I can find it.
The design goal seems straight forward, to discontinue green and blue
for roads and move to red and reddish. For this to happen the decision
was made to shift current primary, secondary and tertiary colours
upwards so primary is now the colour of secondary and secondary the
colour of tertiary. Leaving tertiary white.
Tertiary instead gets to be wider than residential and unclassified
roads, but to be able to spot that you need to have it next to them to
see which is the wider one.
This one simple change of bleaching tertiary however is something I find
to be a great hindrance to mapping efforts, particularly in rural areas
where the roads are isolated and panning over the map, wether in iD or
using default tiles. Currently it is easy to spot tertiary roads snaking
through valleys and over vast desert plains, they are yellow and the non
tertiary roads are white. Tertiary is significant there as it denotes
the roads between the villages and towns that are often unpaved but
still the most important, even the only, road. Lesser white colours
imply the roads not being between larger settlements although they could
lead to hamlets. The guidelines for mapping in Africa state thus.
Removing the colour from tertiary makes all mapping that much harder to
verify and quality check. Currently it is easy to see if a tertiary road
is broken with a white unclassified bridge, not so in the proposed Great
Colour Shift.
Mateusz has been forthcoming with all changes and done sterling work in
displaying different areas and how they will look. But he acknowledges
that this change is not beneficial everywhere on the map and now has a
disclaimer:
Among potential problems are that it is now harder to recognise road
type of given road, especially in situation where there is no
possibility to compare it with other road types.
Such significant change will be confusing for current users of this
style.
UK color coding of roads is well known for many people, for them a new
style - even assuming that it would be intuitive for them - will be less
useful.)
The question really arises if this change is beneficial or not for the
project. Many hours have gone into it and doing CartoCSS on all these
zoom levels is not trivial. But this is a major shift on the front page
of our website, a blow to those who use the default tiles through uMap
or similarly and depend on the UK rainbow road style and makes life
harder for mappers to visually confirm the type of road.
Should this be a new, alternative style instead?
[1] http://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/35586
[2]
https://github.com/gravitystorm/openstreetmap-carto/pull/1736#issuecomment-130592532
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Links:
--
[1] http://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/35586
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Tagging National Forests
John Firebaugh writes: The political boundaries of US National Forests should not be tagged landuse=forest unless the entirety of their area is land primarily managed for timber production. I venture to assert that this is not true for *any* of the National Forests. Here are some examples of areas within National Forests that are not primarily managed for timber production. OK, so say so where so. (Tag in OSM accordingly). If you wish to subtract from the polygon areas which you are absolutely certain no timber production is allowed or possible, go for it. I won't argue. Your list is a good start. Venturing to assert is a good intention, but unfortunately it doesn't quite rise high enough to merit authoritative tagging in OSM. You might say something similar to me: Steve, tagging an entire USFS as landuse=forest means you KNOW the entirety of the forest to be a forest. Well, I could be wrong in tagging the entirety of the forest as forest, but tagging a (whole) forest as forest is not the worst place to begin. Really, that's where we are: more-or-less at the beginning of tagging USFS polygons (with this discussion). Let's get better at it. That's the whole point of this discussion. (I certainly recognize that). Clicking on Firewood Other Products on http://www.fs.fed.us yields this quotable quote: Collecting firewood or other products for personal use is available on many National Forests So, for any given USFS, one might assume yes, one might assume no. It is possibly true that tagging the ENTIRE polygon as landuse=forest is too much if such firewood collection is only allowed on subsets of it. Well, let's identify the subsets and tag those! It is also possibly true that the entire polygon allows the collection of downed wood. If so, keep the entire polygon tagged landuse=forest. Or be prepared to argue the point (with me, and others) why not. Sub-areas? Identify them! Even if you happen to believe that personal wood-gathering for building a fire constitutes timber production You know what? It does. Call it patently ridiculous if you want to be ridiculed by me, but that timber didn't appear like manna from heaven, it was produced by a forest. I mean, really, how can you say otherwise?! there are many areas within National Forests where it's impossible to do so. We should be tagging the areas within them, where timber production is happening or at least possible, as landuse=forest, not the entire political boundary. Well, perhaps we have a happy compromise here. Tell you what: I'll start with the assumption that a forest should be tagged forest. (That's fair, and/or I'm listening to your alternative proposition). WHEN, WHERE and IF you know a particular area to be expressly NOT a forest, you are perfectly welcome to exclude that subset from said polygon. I'm fine with that. See, everybody: this isn't easy or glib. Let's not pretend it is and try to dismiss others with differing views using ham-handed tactics and harsh words. I'm trying to be polite, upstanding, listening and open-hearted. All of us trying to move forward on this topic should strive to do so, too. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-at] Graz+Innsbruck: »Schiene und Straße wurden getrennt«
Friedrich Volkmann wrote: Das ist in Wien kein Konsens, sondern das Werk einer einzigen Person (Railjet). In der Mailingliste, auf Openstreetbugs und in den Map Notes stießen seine Änderungen auf heftige Kritik, und soweit ich mich erinnern kann, hat kein einziger sie gutgeheißen. Das stimmt so nicht. Zumindest ich habe die zweigleisigen Straßenbahnen für gut befunden und finde das immer noch. (Die Ausführung war teilweise nicht optimal, z.B., was Relationen anbelangt, aber die Probleme sind inzwischen behoben. Mit dem neuen Ist-Zustand bin ich zufrieden.) Was allerdings Jonathans aktuelle Änderungen betrifft, verstehe auch ich den Sinn nicht ganz: Wo ein highway=service ausschließlich die Mitbenützung eines Straßenbahngleiskörpers (oft auch wirklich nur auf einem der beiden Richtungsgleise) durch Linienomnibusse darstellt (z.B. in Wien im Bereich Volkstheater / Bellariaschleife), erscheint mir eine Trennung von den entsprechenden Gleis-Tags als weder sinnvoll noch notwendig. Und in den Fällen (sollte es nur außerhalb Wiens geben), wo 2 Gleise noch als 1 Way gemappt sind, ist die Trennung von der Straße auch nur dann sinnvoll, wenn auch wirklich zweigleisig (und präzise, also die tatsächliche Position der Gleise) gemappt wird. Ein getrennter Way mit denselben Knoten wie die Straße bringt niemandem was (auch nicht den Leuten wie Railjet oder mir, die für zweigleisiges Straßenbahnmapping sind). Die Arbeit des zweigleisigen Mappens wird dadurch auch kaum erleichtert, also ist es auch als erster Schritt nicht wirklich geeignet. Kevin Kofler ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] The Proposed Great Colour Shift
I must admit I never really liked the scheme where motorways get the colour
of water... I also grew up with orange/yellow motorways on the map.
But I (try to) complain as little as possible. So I'm glad people are
trying to come up with a 'more international' way of rendering the map. If
that's even possible.
On the other hand, I don't like that the difference between tertiary and
unclassified/residential disappears almost completely.
I don't have the time and energy to set up a rendering chain, so maybe I
better shut up...
Polyglot
2015-08-20 11:59 GMT+02:00 Paweł Paprota ppa...@fastmail.fm:
What you are proposing is basically design by committee
(https://en.wikipedia.org/wiki/Design_by_committee) which is rampant
everywhere in OSM and kills innovation. Everyone wants to pile on their
own cause - be it privacy (see the latest pull request on Github
regarding Gravatar for another viable contender for the Waste of Time
prize) or some weird anarchy/freedom/whatever world views.
At the same time there's a guy (Mateusz) who took on the task of making
the default style not suck - so what do people here do? Of course, let's
discuss this to death until everyone agrees. But then you may find that
no one wants to work with you on this anymore.
In Poland we have this often-used saying with regards to the political
or social situation (yeah, we Poles like to complain a lot!) - it sucks
but at least it's stable!
Paweł
On Thu, Aug 20, 2015, at 11:39, Colin Smale wrote:
That discussion is only a waste of time because people hope that a
consensus will magically appear. The subject of the discussion is
absolutely something which deserves air-time. I am not talking about the
specific case of abandoned railways, but about who has the right to decide
what data has no place in OSM and order its deletion.
What was that famous line in Animal Farm again?
--colin
On 2015-08-20 10:53, Paweł Paprota wrote:
I'm taking bets on whether this thread will have more replies than the
abandoned railroads (100+ and still going strong!) and win the prize
for the Biggest Waste of Time in OSM for 2015.
YES WE CAN('T)
Paweł
On Thu, Aug 20, 2015, at 03:16, Jóhannes Birgir Jensson wrote:
For those that did not check on Mateusz Konieczny diary entries[1[
http://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/35586]],
postings to this mailing list and github discussions then the Proposed
Great Colour Shift might come as a surprise if it is implemented.
According to the github discussion there is an overwhelming
consensus
[2] on moving from current rainbow colour scheme for roads to a
red-yellow only scheme. I am unsure of where this overwhelming
consensus
formed because I never saw it on this mailing list nor on talk-dev nor
on announcements, I admit to be an infrequent IRC user but I didn't
see
this overwhelming consensus there and so far no one has been able to
tell me where it formed or where I can find it.
The design goal seems straight forward, to discontinue green and blue
for roads and move to red and reddish. For this to happen the decision
was made to shift current primary, secondary and tertiary colours
upwards so primary is now the colour of secondary and secondary the
colour of tertiary. Leaving tertiary white.
Tertiary instead gets to be wider than residential and unclassified
roads, but to be able to spot that you need to have it next to them to
see which is the wider one.
This one simple change of bleaching tertiary however is something I
find
to be a great hindrance to mapping efforts, particularly in rural
areas
where the roads are isolated and panning over the map, wether in iD or
using default tiles. Currently it is easy to spot tertiary roads
snaking
through valleys and over vast desert plains, they are yellow and the
non
tertiary roads are white. Tertiary is significant there as it denotes
the roads between the villages and towns that are often unpaved but
still the most important, even the only, road. Lesser white colours
imply the roads not being between larger settlements although they
could
lead to hamlets. The guidelines for mapping in Africa state thus.
Removing the colour from tertiary makes all mapping that much harder
to
verify and quality check. Currently it is easy to see if a tertiary
road
is broken with a white unclassified bridge, not so in the proposed
Great
Colour Shift.
Mateusz has been forthcoming with all changes and done sterling work
in
displaying different areas and how they will look. But he acknowledges
that this change is not beneficial everywhere on the map and now has a
disclaimer:
Among potential problems are that it is now harder to recognise road
type of given road, especially in situation where there is no
possibility to compare it with other road types.
Such significant
Re: [Talk-at] Graz+Innsbruck: »Schiene und Straße wurden getrennt«
Hallo, Michael Maier wrote: Sag mal, bist du eigentlich aus Graz? Dann bitte komm zum Stammtisch nächste Woche Montag! Diesen Vorschlag möchte ich an dieser Stelle unterstützen. Bei einem Getränk lassen sich viele Dinge auf eine sehr viel angenehmere Art besprechen. Eventuell mag die Firma Mentz Datenverarbeitung ja eine Runde ausgeben? Wir treffen uns übrigens im Brot und Spiele City ab etwa 18:00. Liebe Grüße, Stefan ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Moin, kann jemand eine sinnvoll anwendbare Definition von künstlichen / menschengemachten Wasserflächen geben? Fast alle Flüsse in Europa sind vom Menschen deutlich verändert. Bis zu welcher Abweichung vom Verlauf vor menschlichen Eingriffen ist der begradigte Flussabschnitt natürlich? Auch Schifffahrtskanäle verlaufen zu großen Teilen auf alten Flussstrecken und übernehmen die Entwässerungsfunktion des Flusses. Sind diese Teile des Kanals natürlich? Ist ein Stausee, an dessen Stelle sich vor der Stauung ein deutlich kleinerer See befand, natürlich? Oder ist die Fläche des ehemaligen Sees natürlich und der Außenbereich künstlich? Ist ein See, der im 19.Jh zur Trinkwasserversorgung angelegt wurde, natürlich? Sind ehemalige Kiesgruben, die sich durch Grundwasser und Regen in Seen wandeln, oder Löschteiche neben Bauernhöfen natürlich? Sind Gartenteiche mit Folienboden natürlich? Wie soll ein Mapper, der einen Stausee, einen Teich oder einen Graben sieht, entscheiden, ob es sich um ein verändertes, natürliches oder ein künstliches Gewässer handelt? Ich würde die Unterscheidung in künstliche und natürliche Gewässer aufgeben und sie nur nach Größe und Funktion unterscheiden. Gruß Stephan Am 19.08.2015 07:39, schrieb Michael Paulmann: Es gibt Stauseen mit water=lake und natural=water, Stauseen mit nur natural=water und Stauseen mit natural=water und water=reservoir. ... anscheinend taggt ja jeder auch menschengemachte Wasserflächen wie er/sie das will. 2015-08-04 16:00 GMT+02:00 Norbert Kück o...@nkbre.net: Gewässer, die von Menschen NICHT GESCHAFFEN sondern VERÄNDERT wurden, sind KEINE KÜNSTLICHEN Gewässer. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-br] RES: Reunião Periodica - OSM Brasil Peter Krauss
Bom dia Ivaldo! A ECT é a princípio uma aliada do OSM, assim como o IBGE, as prefeituras, etc. O que tenho percebido das conversas paralelas sobre o problema da abertura do CEP é que o brasileiro em geral acredita na seriedade e tem em boa conta os serviços prestados pelos Correios. O entrave que se criou foi com a esfera burocrática da ECT, e a percepção que tivemos é que, mesmo nas diretoriais locais da ECT não há um posicionamento contra o CEP aberto. Havia sim ignorância, desconhecimento do assunto, e estamos buscando mostrar para os administradores da ECT a relevância do CEP aberto... Mesmo entre os administradores e advogados parece um problema bobo e pouco relevante, já que a maioria das pessoas estaria satisfeita com o buscacep.correios.com.br ... O detalhe com o qual nos debatemos é jurídico, e seria resolvido por uma Ação Civil Pública, tal como foi aplicada à ABNT em caso similar http://www.pessoacomdeficiencia.gov.br/app/normas-da-abnt/termo-de-ajustamento-de-conduta. Ainda não entremos com a ação (nós = grupo de interesse independente da OSM) pois acreditamos na conscientização e no diálogo, que em seguida gerariam de fato uma parceria. Seria ótimo ter um interlocutor da ECT aqui na Lista (!), e melhor ainda se você pudesse nos ajudar a esclarecer e dialogar com as outras pessoas da ECT... É uma trabalho de formiguinha, de corpo-a-corpo, mas pode ser muito mais produtivo do que entrar com uma ação jurídica. PS: a boa notícia que comentamos antes é que o Thierry, em nome da OSM, está colhendo os frutos do diálogo que ele fomentou em Brasília, junto à diretoria geral da ECT. O diálogo é relevante e dá resultado! Agradeço desde já por estar escrevendo (!) e sua por sua disposição de ajudar a OSM. Em 19 de agosto de 2015 21:26, Ivaldo Nunes de Magalhães ivald...@gmail.com escreveu: Pessoal, não participei da reunião mas pelas mensagens pude captar algum resquício Bom, eu trabalho nos correios como analista. Coincidentemente trabalhei em Brasília no cadastro e gestão da base de CEP do DNE, no DF e entorno (RIDE), entre 2013 e 2014, quado conheci o OSM. Atualmente estou baseado em Campo Grande/MS, mas não trabalho na área de CEP. Se precisarem de alguma informação, estou à disposição. Relativamente à obtenção da base de CEP local (estados) junto ao representantes regionais, só alerto que disponibilização não será automática. Isso porque eles (estados) terão que consultar à gestor nacional do CEP, em Brasilia. ___ 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-it] josm e server api
Il 08/20/2015 11:59 AM, Simone Cortesi scrisse: a me JOSM funziona regolarmente non hai impostato per sbaglio un proxy? Direi di no. l'URL da te citato è la root dell'API, e da sempre da un 404. Quando avvio josm appare il seguente messaggio: JOSM tried to access the following resources: https://josm.openstreetmap.de/josmfile?page=Styles/Highway_Nodesstyle https://api.openstreetmap.org/api/capabilities https://josm.openstreetmap.de/maps https://josm.openstreetmap.de/wiki/StartupPage but failed to do so, because of the following network errors: java.net.SocketException: Network is unreachable It may be due to a missing proxy configuration. Would you like to change your proxy settings now? Vado nella configurazione del proxy ed e' impostato No proxy. Nella stessa scheda di configurazione della connessione c'e' spuntato: Use the default OSM server URL (https://api.openstreetmap.org/api) Prima che scrivessi qui c'era un altro valore (stupidamente non lo ho segnato) ma l'errore c'era lo stesso. Allora ho spuntato l'opzione di cui sopra. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk] The Proposed Great Colour Shift
On 20/08/2015 02:16, Jóhannes Birgir Jensson wrote: According to the github discussion there is an overwhelming consensus [2] on moving from current rainbow colour scheme for roads to a red-yellow only scheme. I don't think you'll ever get an overwhelming consensus from such a large committee. :) I rendered z0-z11 locally to see what it looks like and was pleasantly surprised - it's much less orange than some of the previous iterations that there have been discussions and blog posts about, and better for it. I'm not quite sure that z7 is quite there (see the difference at http://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/35586#comment31695 ), and obviously any change takes getting used to, but it's not markedly worse than what went before and does resolve the invisible trunk road problem, which really is a problem. Cheers, Andy (SomeoneElse) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] stop deleting abandoned railroads
On 20/08/2015, Russ Nelson nel...@crynwr.com wrote: moltonel 3x Combo writes: But it's equally annoying and tiring to repeatedly encounter the ludicrous kind of railway=abandoned, Then tag it as railway=dismantled. You won't find me defending incorrect tagging of anything. If 'dismantled' is meant to be used for cases like going thru buildings in a housing estate then no, this data just doesn't belong in OSM. moltonel 3x Combo writes: To me the distinguishing criteria between disused and abandoned is wether the rails are still present or not. Indeed. disused means the rails are still there. Abandoned means that the rails are gone. Dismantled (or some people use razed) is when a section of the railbad cannot be seen. Railways that were never there, placed by mistake, should be deleted. The wiki only describes abandoned and disused. Some people have mentioned cases where the rails are still there but trees are growing in the middle so it really should be 'abandoned' and/or there should be a value between 'abandoned' and 'disused'. From what you said earlyer, maybe 'dismantled' is the new 'abandoned' and 'abandoned' sits somewhere between 'dismantled' and 'disused' ? Maybe you could give the wiki some TLC. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Tagging von Bächen als waterway=ditch
On Thursday 20 August 2015, Stephan Wolff wrote: Moin, kann jemand eine sinnvoll anwendbare Definition von künstlichen / menschengemachten Wasserflächen geben? Für stehende Wasserflächen: natürlich (also water=lake/pond): die Wasserfläche existierte schon vor dem Beginn menschlicher Eingriffe/würde ohne menschliche Eingriffe existieren. Für durch Menschen modifizierte Wasserflächen müsste man hier eine quantitative Grenze einführen, Beispiele: Schluchsee, Victoriasee, also durch Aufstauung vergrößerte natürliche Seen. So was wird im Allgemeinen immer noch als See betrachtet, aber es gibt natürlich Grenzen (Riesenstausee wo vorher nur ein Tümpel war). In der Praxis ist das aber eher die Ausnahme. Für Wasserläufe: natürlich (also waterway=river/stream und ggf. waterway=riverbank bzw. water=river für das Polygon): es hat vor den menschlichen Eingriffen einen Wasserlauf gegeben, der im Verlauf und in seinem Einzugsgebiet dem jetzigen ähnelt. 'ähnelt' ist natürlich schwammig, in der Praxis ist das meist recht eindeutig, aber es gibt natürlich Problemfälle. Beispiel: Oberrhein: der Rheinseitenkanal führt den größten Teil des Rheinwassers und ähnelt im Verlauf definitiv dem alten Rhein. Da dieser aber noch parallel existiert ist dem üblichen Verständnis nach der Altrhein immer noch der Rhein und der parallele Rheinseitenkanal ein künstlicher Kanal. Das liegt auch daran, dass der Altrhein in dem Bereich immer noch durchgehend Wasser führt während Altarme von Flüssen anderswo oft reine Stehgewässer sind. Auch bei kleineren Bächen im Flachland kann das ein Problem sein, wenn zum Beispiel ein Bach im Bereich landwirtschaftlicher Nutzflächen recht weiträumig umgeleitet und das ursprüngliche Bachbett komplett zugeschüttet wird. Meines Erachtens kann man sowas recht weitreichend noch als natürlich interpretieren, solange das eindeutig ist (also nicht ein ganzes Grabennetzwerk als waterway=stream nur weil irgendwo dadurch früher mal ein Bach floss). Die Bezugnahme auf die Vergangenheit vor den menschlichen Eingriffen ist natürlich im Sinne der Überprüfbarkeit etwas heikel. Das macht die Unterscheidung aber noch nicht generell sinnlos. Wer die Unterscheidung beibehalten möchte, sich aber auf natürlich im Sinne von 'in unverändertem natürlichen Zustand' beziehen möchte endet unweigerlich dort, wo wir bei forest/wood sind, was sicher nicht erstrebenswert ist. Wer die ganze Unterscheidung komplett abschaffen möchte sollte bedenken, dass dies den Nutzen der Daten insbesondere in wasserbaulich stark erschlossenen Gebieten enorm einschränken würde. In jedem Fall: der Ausgangspunkt dieses Threads waren Fälle, in denen die Situation recht eindeutig ist. -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] The Proposed Great Colour Shift
I'm not proposing anything. Merely observing.
I am not the only one confused about which definition of overwhelming
consensus was used...
--colin
On 2015-08-20 11:59, Paweł Paprota wrote:
What you are proposing is basically design by committee
(https://en.wikipedia.org/wiki/Design_by_committee) which is rampant
everywhere in OSM and kills innovation. Everyone wants to pile on their
own cause - be it privacy (see the latest pull request on Github
regarding Gravatar for another viable contender for the Waste of Time
prize) or some weird anarchy/freedom/whatever world views.
At the same time there's a guy (Mateusz) who took on the task of making
the default style not suck - so what do people here do? Of course, let's
discuss this to death until everyone agrees. But then you may find that
no one wants to work with you on this anymore.
In Poland we have this often-used saying with regards to the political
or social situation (yeah, we Poles like to complain a lot!) - it sucks
but at least it's stable!
Paweł
On Thu, Aug 20, 2015, at 11:39, Colin Smale wrote:
That discussion is only a waste of time because people hope that a consensus
will magically appear. The subject of the discussion is absolutely something
which deserves air-time. I am not talking about the specific case of
abandoned railways, but about who has the right to decide what data has no
place in OSM and order its deletion.
What was that famous line in Animal Farm again?
--colin
On 2015-08-20 10:53, Paweł Paprota wrote:
I'm taking bets on whether this thread will have more replies than the
abandoned railroads (100+ and still going strong!) and win the prize
for the Biggest Waste of Time in OSM for 2015.
YES WE CAN('T)
Paweł
On Thu, Aug 20, 2015, at 03:16, Jóhannes Birgir Jensson wrote: For those that
did not check on Mateusz Konieczny diary
entries[1[http://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/35586]],
postings to this mailing list and github discussions then the Proposed
Great Colour Shift might come as a surprise if it is implemented.
According to the github discussion there is an overwhelming consensus
[2] on moving from current rainbow colour scheme for roads to a
red-yellow only scheme. I am unsure of where this overwhelming consensus
formed because I never saw it on this mailing list nor on talk-dev nor
on announcements, I admit to be an infrequent IRC user but I didn't see
this overwhelming consensus there and so far no one has been able to
tell me where it formed or where I can find it.
The design goal seems straight forward, to discontinue green and blue
for roads and move to red and reddish. For this to happen the decision
was made to shift current primary, secondary and tertiary colours
upwards so primary is now the colour of secondary and secondary the
colour of tertiary. Leaving tertiary white.
Tertiary instead gets to be wider than residential and unclassified
roads, but to be able to spot that you need to have it next to them to
see which is the wider one.
This one simple change of bleaching tertiary however is something I find
to be a great hindrance to mapping efforts, particularly in rural areas
where the roads are isolated and panning over the map, wether in iD or
using default tiles. Currently it is easy to spot tertiary roads snaking
through valleys and over vast desert plains, they are yellow and the non
tertiary roads are white. Tertiary is significant there as it denotes
the roads between the villages and towns that are often unpaved but
still the most important, even the only, road. Lesser white colours
imply the roads not being between larger settlements although they could
lead to hamlets. The guidelines for mapping in Africa state thus.
Removing the colour from tertiary makes all mapping that much harder to
verify and quality check. Currently it is easy to see if a tertiary road
is broken with a white unclassified bridge, not so in the proposed Great
Colour Shift.
Mateusz has been forthcoming with all changes and done sterling work in
displaying different areas and how they will look. But he acknowledges
that this change is not beneficial everywhere on the map and now has a
disclaimer:
Among potential problems are that it is now harder to recognise road
type of given road, especially in situation where there is no
possibility to compare it with other road types.
Such significant change will be confusing for current users of this
style.
UK color coding of roads is well known for many people, for them a new
style - even assuming that it would be intuitive for them - will be less
useful.)
The question really arises if this change is beneficial or not for the
project. Many hours have gone into it and doing CartoCSS on all these
zoom levels is not trivial. But this is a major shift on the front page
of our website, a blow to those who use
Re: [OSM-talk] stop deleting abandoned railroads
On 20/08/2015, Russ Nelson nel...@crynwr.com wrote: moltonel 3x Combo writes: The demolished: prefix only makes sense when there is something left of the former feature, typically rubble (useful for example to alert boattripers of the hazard). When there is nothing left in reality, there should be nothing left in OSM. Question: should we tag the aqueduct underneath Sunrise Highway between Aqueduct Raceway and Freeport, NY? I'm not at all familliar with that area, please provide some links. Deleting an object is hardly different from editing it as far as osm history is concerned. Except that deletion excises it from the database that you see when make an API call. So does editing. When you change the geometry or tags of an object, the old versions are not downloaded/displayed by you editor unless you take special action. I know that outside of Potlach1 that special action is a bit more complicated, but that is just an API issue that will hopefully get fixed someday. In the case of dismantled railways, that is not accurate. There *is* a dismantled railway there, and you can tell because the railway was at point A and at point B, and you can still see it there, and so you should expect to see it in-between. The argument (which is not making any progress so this might be my last comment on it) is between *is* and *was*, and where to draw the line. If there *is* an abandoned railway it can be mapped. If there *was* a railway it cannot be mapped. abandoned isn't a synonym of was. See for example http://osm.org/go/esz3FWUuB- (toggle satellite imagery). There *is* an abandoned railway south of the river, there *was* a railway north of it. The fact that you can infer that the railway was indeed there because it's clearly visible again at http://osm.org/go/esz18LcmF- (and visible all the way in the GSGS 3906 imagery) doesn't matter. We've discussed a few criterias to distinguish between *is* and *was* on this thread, but you've dismissed even the most basic A building has not been constructed at that location one. On the subject of is/was criterias, I'd like to weight against the less basic railway grade slope one. Firstly because railways usually followed existing flat grades instead of following them, secondly because in other cases the cuttings and embankments should be mapped for themselves rather than implied by a railway=abandoned. There might be some cases where that argument still makes sense (montainside railways come to mind), but it needs to be evaluated case by case IMHO. I understand that most people don't give a crap about map feature X, Y, and Z. I get it, really I do. I look at things in OSM myself and wonder why the hell did you map that?? Who cares?? And when it comes to railways, there's a lot of people who don't give a crap. Fine. Go ahead. Don't care. But I do. So don't delete the things that I (and other railfans) have added. For the last time, this isn't about esoteric mapping topics (abandoned railways is actually quite popular in OSM), but about reconising then something just doesn't exist anymore and (in another part of this thread) about wether mapping the past is acceptable in OSM at all. From whence comes this impulse to destroy other people's work? Cuz it seems pretty anti-community, anti-mapper, and anti-OSM. Quality assurance. We all want the map to be as correct as possible, and that sometimes require deleting data. The only anti-* case is when the decision to modify/delete is controversial but not discussed. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM.org rendering and features [was Re: The Proposed Great Colour Shift]
W dniu 20.08.2015 17:53, Andy Townsend napisał(a): On 20/08/2015 16:25, Ben Laenen wrote: Thing is that UK won't ever be happy with another colour scheme and the rest of the world won't ever be happy with a UK scheme. ... and then in the UK we can start arguing about and English style vs a Scottish one and then a Yorkshire one vs Surrey :) I wanted to start my own topic one day, but I feel that you have touched very important and general problem related to rendering, which is amplified by current changes authored by Mateusz. We have very uncomfortable situation with rendering styles on our main website: out of 5 styles available only 2 are general, and only one - default one - is to some reasonable extent an OSM community effort (technically it's open, in practice not much people are active there, it is rather detached from other parts of OSM and is rather conservative socially). HOT is kind of a special task force and community in itself, as far as I understand, so I don't count it as a general style. Goals of default style are also non-uniform: https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md#purposes which makes it even harder to deal with. It was just a matter of time if someone will try to make some bigger changes, which will result in explosion. And here we are... *** My point is: we - as an OSM community - need more styling options, because default osm-carto style is unable to effectively take all the responsibilities and expectations. There are many solutions to consider. All of them have their strengths and weaknesses, in short they can be: 1. osm-carto-devel, which can be visually less elegant, but more intended for the mappers to see their work. However it means double the resources we use today, so this may be hard to achieve. 2. Layers like http://osm24.eu/ (POIs with opening hours) or http://osmapa.pl/w/area/ (highway:area=* test rendering), which are much lighter than full style - however they don't blend with underlying style seamlessly. 3. Vector tiles, which allow having plenty of styles available and high personalization, but on the other hand deserve additional infrastructure (I guess less than with osm-carto-devel?) and are probably much slower to render, because it's done on the client side. I believe 3. is the future. We won't be able to serve every possible style in any other way - be it UK, US, but also with local names in every language etc. It will also allow people to learn styling and enhance our collective skills in this regard. But maybe we could also use other styling options in the meantime. I also think about adding additional features, like support for umap ( http://umap.osm.ch ), which can help some users to create their own small maps based on OSM, and indoor or even 3D viewer included on the main website (think about multi-level malls and railway stations - they are unreadable today). I don't know how many resources we have to extend current situation, but rendering maps is simply too important for the people to live with just one general purpose style influenced by the community. -- The train is always on time / The trick is to be ready to put your bags down [A. Cohen] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-at] Graz+Innsbruck: »Schiene und Straße wurden getrennt«
Hallo Simon, ich gebe dir grundsätzlich Recht, dass es problematisch ist zwei übereinander liegende Kanten im Editor schnell zu erkennen und voneinander zu unterscheiden. Auch sehe ich ein, dass meine Edits nicht ganz den (zuletzt am 3.12.2014 [1]) aktualisierten Richtlinien entsprechen. Ich habe es eher als einen ersten Schritt gesehen, einmal Straße von Schiene zu trennen, bevor man dazu übergeht eine eigene Kante für jede Fahrtrichtung der Tram zu mappen und die Fahrbahn für Auto/Bus etc. entsprechend [1] auszurichten. Dass zu [1] scheinbar keine Diskussion stattfand, war mir nicht bewusst. Allerdings erscheint mir die Methode sinnvoll und abgesehen von Graz und Innsbruck wird sie meines Wissens inzwischen auch überall im deutschsprachigen Raum angewandt. Da die Mehrheit (und damit nehme ich auch Bezug auf den neuen Beitrag von Michael) mit den übereinander liegenden Kanten nicht glücklich zu sein scheint, will ich mich anbieten sie gemäß [1] neu zu mappen. Sprich: - Wo sich zweispurige Tramgleise mit dem Straßenverkehr diesselbe Spur teilen, werden die zwei Gleise einzeln gemappt (mittig der Gleise) und die Straße als Kante dazwischen (siehe zb. Taborstraße, Wien [2]) - Wo zweispurige Tramgleise von Straßen in beide Fahrtrichtungen umschlossen sind, werden die Gleise einzeln gemappt (mittig der Gleise) und die beiden Straßen- fahrbahnen beidseitig davon (siehe zb. Rennweg, Wien [3]) - Wo Tramgleise einspurig verlaufen und sich mit Bus/Auto die Spur teilen, werden beide Spuren einzeln UND LEICHT VERSETZT GEMAPPT(?) (siehe zb. Taborstraße, Wien [4]) ODER MIT DENSELBEN NODES (?) Was sind die Meinungen hierzu? Die Zuordnungsfehler im Tagging, die Michael dazu veranlasst haben meine Edits zu reverten, bedaure ich. Ich werde in Zukunft besser darauf achten, dass mir sowas nicht passiert. Grundsätzlich sehe ich es voll und ganz ein, dass sich einige gestört fühlen, wenn jemand von außen (ich bin Wiener) Änderungen vornimmt, ohne sich davor mit der lokalen Community abzusprechen. Das habe ich aus schlichter Unerfahrenheit verabsäumt und hoffe auf eure Nachsicht. Der Stammtisch nächsten Montag, kommt etwas knapp. Bin mir nicht sicher, ob sich das für mich ausgeht. Ansonsten bitte ich um eure Meinung hier in der Mailinglist. Grüße, Jonathan [1] https://wiki.openstreetmap.org/w/index.php?title=DE:Tag:railway%3Dtramdiff=nextoldid=1112007 [2] https://www.openstreetmap.org/#map=19/48.21670/16.38187 [3] https://www.openstreetmap.org/#map=19/48.19637/16.38224 [4] https://www.openstreetmap.org/#map=19/48.21306/16.38046 Date: Wed, 19 Aug 2015 22:12:48 +0200 From: simon.leg...@gmail.com To: talk-at@openstreetmap.org CC: gallag...@mentzdv.de Subject: Re: [Talk-at] Graz+Innsbruck: »Schiene und Straße wurden getrennt« Hallo Jonathan, mir ist nicht klar, nach welchem der Punkte von der Wiki-Seite (welche im September 2014 ohne einer mir bekannten vorausgegangenen Diskussion und unabhängig von der englischen Seite geändert wurde [1]) du in Innsbruck und Graz vorgegangen bist. Auf der Seite heißt es: Wo Trams zweispurig auf einer Straße verlaufen, die baulich nicht in Richtungsfahrbahnen getrennt ist, werden die Tramlinien als zwei Linien (jeweils in der Mitte der einzelnen Gleise) gezeichnet und die Straße als Linie dazwischen. Die Prämisse ist für den Großteil in Innsbruck und Graz erfüllt. Also müsste die Straßenbahngleise völlig unabhängig von der (dazwischen liegenden) Straße gemappt werden. Soweit ich das gesehen habe, hast du die Schiene deckungsgleich mit der Straße erfasst und die gleichen Knoten verwendet. Für eine Pflege von einem der beiden Objekte halte ich das sehr unpraktisch, weil man zuerst feststellen muss, dass es zwei übereinanderliegende Objekte sind und nachher noch das richtige selektieren muss. Weder das eine noch das andere tragen zu einer einfachen Bearbeitung bei. In Innsbruck gibt es teilweise einen eigenen Gleiskörper, der von Linienbussen mitverwendet wird (beispielsweise im Bereich Höttinger Au oder Sillpark). Wenn man nach dem Auftrennen zwei Wege für die Straßenbahn, ein/zwei Weg/e für den Busverkehr hat und daneben sich MIV und Fußgänger und Radfahrer (gemäß [2]) teilen, halte ich das für ein großes Ungleichgewicht. Ich habe erst jetzt festgestellt, dass sich deine Anpassungen dem Mapping von Hibenny überlagert haben. Dieser Benutzer hat schon mehrfach [3, 4] auf stölperhafte Weise das Straßenbahnnetz umgemappt und hat auf meine Nachrichten nie reagiert. In der Hoffnung auf allseits zufriedenstellende Lösung … Simon [1] https://wiki.openstreetmap.org/w/index.php?title=DE:Tag:railway%3Dtramdiff=1090537oldid=1027841 [2] https://wiki.openstreetmap.org/wiki/DE:Key:cycleway [3] https://lists.openstreetmap.org/pipermail/talk-at/2014-August/006850.html [4] https://lists.openstreetmap.org/pipermail/talk-at/2014-September/006964.html ___ Talk-at mailing list Talk-at@openstreetmap.org
Re: [Talk-at] Mitgliedschaft
On 08/20/2015 03:30 PM, Jonathan Gallagher wrote: ich konnte nicht herausfinden, wie ich Mitglied in der Talk-at Mailing List werde. Deshalb frage ich einfach mal hier nach, ob das denn möglich wäre. Natürlich ist das möglich und die Anmeldung ist auch nicht unbedingt geheim: https://lists.openstreetmap.org/listinfo/talk-at Auffindbar beispielsweise über https://wiki.openstreetmap.org/wiki/Mailing_lists Ich hab dich jetzt übrigens schon angemeldet, du solltest also bereits ein Willkommensmail erhalten haben. lg, Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] The Proposed Great Colour Shift
I'm happy to support a shades of red/yellow road system for the default map. The UK colours only really work at small scale with heavy casing (with landuse eg forests muted). The green for trunk roads used for OS 1:50,000 is only recent, much darker than the green used for OSM, and a cartographical abomination (in my view), being much too dominant. Until a few years ago, it was only motorways that were different. The colours at 1:25,000 have always been slightly different again. As ever, if you want something done your own particular way, do it yourself. Rendering isn't *that* difficult. The default map needs to work at all zooms, and all* latitudes. *excluding the tricky bits around the poles, obviously ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] Apresentação e duvida
Os tipos de via estão descritas no wiki: http://wiki.openstreetmap.org/wiki/Key:highway mais especificamente, na primeira tabela Roads. Num mundo ideal, vias expressas (motorway) não dão direto em vias residenciais, mas no mundo real isto nem sempre acontece. []s Arlindo 2015-08-20 13:35 GMT-03:00 Felipe Castanho felipequadr...@gmail.com: Outra coisa Arlindo, existe regras de conectividade em respeito a hierarquia das vias? Eu pergunto isso porque na empresa que eu trabalhei, nós não podiamos por exemplo tornar uma via de hierarquia mais alta de repente em hierarquia mais baixa. Por exemplo a Azul era apenas para estradas nacionais, a Verde só poderia nascer da conexão com uma Azul ou Verde e só poderia terminar em outra verde ou em outra azul, nunca terminar em uma vermelha, a vermelha por sua vez poderia surgir e terminar em uma azul, verde ou vermelha, mas jamais poderia terminar em uma laranja, amarela ou branca. Voce poderia falar um pouco sobre isso ou me apontar um documento aonde eu consiga aprender sobre isso uma vez que eu não encontrei exatamente o que estou procurando. Obrigado 2015-08-20 0:37 GMT-03:00 Felipe Castanho felipequadr...@gmail.com: Acredito que seja esse: Caminho: Rua Ribeirão Claro (234368026) Intersecção com a Helio Pellegrino 2015-08-19 19:33 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: 2015-08-19 17:46 GMT-03:00 Felipe Castanho felipequadr...@gmail.com: Muito obrigado Arlindo Então a rota do onibus é modificada apenas porque vai adicionar mais links uma vez que a original passava por DC e agora tem que passar por DP e em seguida por PC correto? Não esta havendo propriamente um desvio na rota, apenas uma correçào. correto? Exatamente. Outra coisa, não estou conseguindo adicionar uma restrição de nao retornar (No U-Turn) Voce pode me explicar? Imagine que de acordo com o seu esquema, exista outra linha paralela a AB nesse caso representando uma avenida com divisor fisico e na realidade voce não pode dirigir de AP e retornar em P sentido PA, como fazer isso? Depende de como está mapeado, se no local do não-retorno há apenas um ponto (isto é, as duas avenidas se tocam junto com a transversal em um único nó) ou se há dois pontos (P1 e P2), um para cada sentido da avenida. Pode passar o link da região? []s Arlindo 2015-08-19 14:14 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: Olá Felipe. É isso mesmo! Explicando: suponha o seguinte cruzamento: [image: Inline image 1] Se existem as vias AB e CD, e você adiciona uma restrição de conversão no ponto P, o que acontece na prática é que as vias são segmentadas (AB vira AP + PB, CD vira CP + PD), com isso na prática são modificadas duas vias e criadas duas vias. Além disso, quaisquer rotas que passem nas ruas AB ou CD também são alteradas (afim de incluir a nova via). PS: A abreviação de OpenStreetMap é OSM ;) []s Arlindo 2015-08-19 13:00 GMT-03:00 Felipe Castanho felipequadr...@gmail.com: Ola a todos, meu nome é Felipe Castanho, a muitos anos atras eu trabalhei com mapeamento, mas fazem 6 anos parei de atuar e estou me interessando novamente pelo assunto, em especifico pelo OMS. Eu peguei uma via como exemplo para tentar entender na pratica como o OMS funciona e fiquei um pouco assustado com as mudanças que ele sugeriu quando apliquei uma restrição de manobra. Vou explicar melhor. Na cidade de SP, região da Vila Olimpia, tem o cruzamento da Av. Helio Pellegrino com a Rua Ribeirão Claro. Na realidade, existe duas restrições de manobras de quem esta na Helio para entrar na Ribeirão, que são: proibido virar a esquerda e proibido retornar. Selecionei o nó, o OMS me apresentou um quadrado com as duas vias e quando cliquei na helio apareceu duas setas verdes, sendo uma delas na ribeirão claro, cliquei nessa seta para aplicar a restrição de manobra e a seta ficou vermelha. Até ai ok. O problema é quando ele me listou 6 alterações, modificando e criando novas estradas primarias tanto para a Helio como a Ribeirão, e ainda por cima modificou uma rota de onibus 477P-10, por fim ele cita a proibição de virar a esquerda. O que me preocupa são essas outras modificações, principalmente a rota do onibus, Talvez essa seja de fato a rota do onibus e eu estou estragando ou talvez a rota seja automatizada e não levava em conta essa restrição. Então eu gostaria de uma ajuda aqui, meu intuito é ajudar e não atrapalhar. Obrigado! Outra questão: como posso adicionar a restrição proibido retornar nesse mesmo cruzamento? OBSERVAÇÃO: eu não apliquei as modificações ok. ___ 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] The Proposed Great Colour Shift
Hi, On 08/20/2015 03:16 AM, Jóhannes Birgir Jensson wrote: Removing the colour from tertiary makes all mapping that much harder to verify and quality check. Currently it is easy to see if a tertiary road is broken with a white unclassified bridge, not so in the proposed Great Colour Shift. ... Should this be a new, alternative style instead? Disadvantages of offering and maintaining 2 different styles: 1. uses more disk space on tile servers 2. uses more time to render tiles (i.e. slower updates, or more hardware required) 3. harder to keep styles current when making improvements Your use case of easily recognizable tertiary road in sparsely populated regions is valid, but perhaps it is niche enough to accept that it need to be served by the main map style. I'm in favour of the change simply because it is a change. As a project, we must take great care not to ossify. Humans are inherently change averse; most people prefer the same as yesterday most of the time. If we allow the project to become too averse to change then we'll never see progress. (What, API 0.7 you say? Just when I had 0.6 hardcoded in my 37 applications, no way!) This is not change for change's sake (although if it were my decision, I'd even be tempted to do that just to keep us alert) - this is a well thought out suggestion and I don't see why we shouldn't, after all these years, do something else, colour-wise, for a while. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] Solicitação LAI (Lei de Acesso à Informação) ao IPP sobre o Geolog
Prezados, agradeço pela resposta. Com relação aos dados mencionados do PORTALGEO, tais como: fronteiras de bairro, endereçamento, contornos de construções etc., gostaria de perguntar se as mesmas restrições se aplicam, ou se há uma flexibilização da licença neste caso. Para contexto, meu intuito é, caso seja possível, importar os dados no OpenStreetMap [1], projeto que disponibiliza um mapa de todo o mundo sob licença livre, a partir de dados contribuídos por pessoas, empresas e governos. No Brasil, o OSM conta com dados públicos de diversos órgãos / esferas, desde a nível federal com dados do IBGE até o nível municipal, com contribuições da prefeitura de Vitória. Recentemente, tivemos aprovação para importar dados do portal Geolog da prefeitura de São Paulo. Mais especificamente, os dados importados no OSM são livres para qualquer tipo de utilização, inclusive comercial, e os dados relativos a autoria original viriam apenas como metadados dos objetos e opcionalmente numa página apartada, sem legenda no mapa principal. Agradeço mais uma vez a atenção dispensada. Att., Arlindo Pereira 1: http://www.openstreetmap.org/about 2015-08-20 13:13 GMT-03:00 Armazem de Dados DIG arma...@pcrj.rj.gov.br: Prezado Sr. Arlindo Pereira, Respondendo sua solicitação para a Assessoria de Comunicação do IPP Atenciosamente, Equipe Armazém de Dados 1) O Cadlog é domínio público? Sim. O Armazém de Dados é um site de disseminação de informações sobre a Prefeitura do Rio. A utilização do seu conteúdo é livre para fins não comerciais e com a devida citação de fonte Prefeitura da cidade do Rio de Janeiro – Instituto Pereira Passos (IPP) – Site Armazém de Dados. Se o Cadlog não for de domínio público: (mesmo assim, acho que pode ser interessante enviar a explicação) 2) Posso utilizá-lo para fins comerciais? Não. 3) Posso fazer trabalhos derivados em cima do mapa (ou seja, modificá-lo e publicar)? Consideramos o CADLOG um aplicativo (Mapa Digital) fechado cujo link pode ser inserido em aplicações ou sites desenvolvidos pelo usuário. Sempre com a citação da fonte. No site do Armazém de Dados, dentro do PORTALGEO, o usuário encontra várias bases que podem ser usadas em projetos. 4) Se eu fizer um trabalho derivado, esse trabalho tem que dar atribuição? Sim. Prefeitura da cidade do Rio de Janeiro – Instituto Pereira Passos (IPP) – Site Armazém de Dados 5) Se tiver atribuição, essa atribuição tem que ficar como legenda do mapa ou pode ficar em uma página apartada? Legendada no mapa. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk] The Proposed Great Colour Shift
On 8/20/2015 9:32 AM, john whelan wrote: As someone affected I wish to dissent therefore you do not have consensus not every one consents. Although not essential to the style discussion, I think it's important to correct this point. Consensus is not unanimity. https://tools.ietf.org/html/rfc2418#section-3.3 is a good read, as it mentions mailing lists. Another part is identifying and resolving of concerns. This does not mean everyone will agree with how their concern is resolved, which is impossible when two concerns do not have a compatible resolution. The decision to merge or not lies with the maintainers, and ultimately, with Andy. We'll look at comments on the Github issue, the cartography change and come to a final decision. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-at] Mitgliedschaft
Hallo, ich konnte nicht herausfinden, wie ich Mitglied in der Talk-at Mailing List werde. Deshalb frage ich einfach mal hier nach, ob das denn möglich wäre. Ich habe einige Dinge beizutragen und es wäre toll, wenn ich zwecks Zeitersparnis die Autorisierung umgehen könnte. Grüße, Jonathan (user: Weltstaat) ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] stop deleting abandoned railroads
On Thu, Aug 20, 2015 at 7:12 AM, Russ Nelson nel...@crynwr.com wrote: Frederik Ramm writes: The trouble is that I'm being threatened with having my contributions deleted! DELETED! Why incentive do I have to correctly tag, when people are saying Go ahead, I'm just going to delete it anyway and I'm going to encourage other people to do the same thing. Russ, seriously. Many people already told you that if it is removed physically, then we remove it in OSM as well. Even if you use a tag dismantled, the point isn't changing : we don't keep removed features in OSM. We map the present (and basically, I'm also if favour to delete the future, like the planned stuff when it's not 100% sure). There is a large consensus on that in the community. Why are you insisting ? If you like, check the OHM project which is dedicated for historical maps. I got some examples from the net: [1] https://commons.wikimedia.org/wiki/File:Dunstable,_Dismantled_railway_and_National_Cycle_Network_Route_6_-_geograph.org.uk_-_146322.jpg where is the railway here ? were are the rails ? why should we keep any mention about rails when it's a cycleway now ? map what we see, the path or track and the cuttings/embankments. [2] http://ukbeach.guide/photos/uk-photos.php?photo=15295 [3] http://www.geograph.org.uk/photo/2496379 disused is fine here. [4] https://outoftheloopdotcom.files.wordpress.com/2012/06/p6090099.jpg Who knows that this track was a railway from 1881 to 1961 ? why should we keep any railway tag here ? Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-ja] 国立公園 (national_park) の編集について
瀬戸です。 正確にはオープンデータの類とは異なるデータセットであること（OSMのライセンスとは相容れないので、積極的に残す理由が現状ない） 研究で以前利用したこともあるのですが、本データが他のデータに勝るような正確性があるかというと、個人的な感触ではそうでもない点 から、特にデータインポートに関する議論を経ずに行われた作業に対してライセンス的に疑念があるものであれば、リバートすることが現実的でないかと思います。 2015年8月17日月曜日、Satoshi IIDAnyamp...@gmail.comさんは書きました: いいだです。 遅くなってしまいましたが、変更セットへのコメントを行っています。 https://www.openstreetmap.org/changeset/33048672 2015年8月11日 9:22 Satoshi IIDA nyamp...@gmail.com javascript:_e(%7B%7D,'cvml','nyamp...@gmail.com');: いいだです。 ありがとうございます。 ライセンス互換性、個別の許可の取得 なるほど、個別の許諾交渉というのはひとつの手かもしれませんね。 環境省生物多様性センターさんに知り合いはいないので、 正面からあたってみるしかないかんじですが、、、 OSMFJとして行うか、個人として行うかは別として、ちょっと検討してみます。 （事後報告になっちゃうのはかなり厳しい気がしています） 政府標準利用規約をCC-BY互換に改定 はい、議論の俎上にあがる可能性が高いと伺っています。 ただ、ライセンス変更の結果がでるのは早くても今年度末かと思いますので、 待つのはちょっと厳しいかなぁ、とも感じています。 # CC-BY 4.0互換（2.1 JPではなく）になると、 # OSMでも利用できる可能性が高くなることもあり、 # 委員会での議論の行方は僕もたいへん注目しています。 トレースについて これも、調製をおこなった地図（作品）の利用にあたるかと思いますので、 調製された主体に確認が必要ですね。環境省さんかぁ。。。 海上の公園について 明確に議論がされたことは無いと思っています。 海岸線を1km延伸した海上部分も含めたほうがよい、ということで、納得しました。 できれば、インポート作業されたかたの意見も伺いたいなぁ。。。 2015年8月9日 17:42 centree oki_aic...@yahoo.co.jp javascript:_e(%7B%7D,'cvml','oki_aic...@yahoo.co.jp');: centree です。 私も詳しくありませんが… (1) ライセンスについて 政府標準利用規約というのがあるのですね。恥ずかしながら存じ上げませんでした。 http://www.biodic.go.jp/trialSystem/info/nps.html この辺のデータをコンバートして投入したいなら、確かに量も量ですし、OSMFJで許諾をとって頂いておいた方が安心かと思います。 OSMはそんなに黒い（？）要途を主な目的としてはいないと思うので、交渉や問い合わせは可能なのではないかと思いますが 確かにOSMに投入すると、後の用途は限っていませんので『公序良俗』に照らし合わせ、どのように判断がでるかは未知数ですね。 ちなみに、もし、上記のような生のデータではなく、 http://www.env.go.jp/park/yakushima/intro/files/area_3.pdf のようなP DF媒体からのトレースということになると、背景画に承認番号付きの地理院の地図が使われているので 地図タイルのトレースのみが許諾されているOSMへの投入はNGなのではないかなと思います。 (2)海上の公園について 国立公園の資料を見ると、海上もしっかり公園と称されているようなので、基本的には含めるべきなのかなと思います。 ただ、瀬戸内海国立公園なんかは範囲も広く、なかなかスケールの大きい作業になりそうですが… centree - Original Message - *From:* tomoya muramoto muramototom...@gmail.com javascript:_e(%7B%7D,'cvml','muramototom...@gmail.com'); *To:* OpenStreetMap Japanese talk talk-ja@openstreetmap.org javascript:_e(%7B%7D,'cvml','talk-ja@openstreetmap.org'); *Date:* 2015/8/9, Sun 15:19 *Subject:* Re: [OSM-ja] 国立公園 (national_park) の編集について muramotoです。 インポートやライセンス関係には不案内なため、類似の経験をお持ちの方のご意見を待ちたいところですが、ざっと調べた上での所感です。 (1)ライセンスについて ・環境省生物多様性センターのライセンスは、ご指摘のとおり、利用用途に制限があるようです(「公序良俗」制限)。一方でODbLには利用用途に制限がないようです。ODbLのほうが緩いので、使えないのではないかと思います。 ・そのため、データをOSMで利用する場合は、個別に許諾を得る必要があると思います。例えば、国土地理院はGSImaps利用のライセンスで「公序良俗」の制限を課していますが、大変有難いことにOSMFJの方が個別に許諾を取っていただいたとのことなので、私は安心してデータを利用させていただ いております。 http://wiki.openstreetmap.org/wiki/JA:GSImaps ・もしくは、政府標準利用規約をCC-BY互換に改定しようという動きもあるようなので、その結果を待つのもひとつの手だとは思います。 https://www.kantei.go.jp/jp/singi/it2/densi/kwg/dai2/siryou2.pdf (細かいですが、環境省生物多様性センターのライセンスは政府標準利用規約（第1.0版）に準拠のようです。) (2)海上の公園について ・海上が国立公園として指定されている(海域公園地区または普通地域)のであれば、海上も範囲に含めるべきだと思います。国立公園では、海岸から1kmまで「普通地域」として指定されているようです。 ・過去の議論において、海上を含めるのは不都合であるという結論に達したのであれば、それに従って良いと考えますが、個人的には議論の流れを知りたいとは思います。 2015年8月8日 22:31 Satoshi IIDA nyamp...@gmail.com javascript:_e(%7B%7D,'cvml','nyamp...@gmail.com');: いいだです。 国立公園のデータについて、インポート、あるいはトレースを行っているような形跡が見受けられました。 例えば、この編集です。 https://www.openstreetmap.org/changeset/33048672 この編集には、いくつかの問題があります。 1. 議論がされていない talk-ja, imports、どのメーリングリストにも、事前の相談が行われていません。 2. ライセンスの互換性 ライセンスを確認すると、政府標準利用規約(ver. 1.1)のようです。 しかしながら、その互換性については、いまだ議論が行われておらず、 インポート作業を行うには、法的な互換性が保たれていることが必要かと思っています。 （いわゆる、3条ア 公序良俗条項、のところがメインです） 逆に言えば、ここが担保されていれば、多くのデータが利用可能になります。 議論をし、互換性について議論したいです。 ■方針について データ自体については、有用なデータだと感じていますので、 できれば使い続けたいと考えています。 ただし、海の上にまで公園の範囲が及んでしまうなど、 疑問点がいくつかありますので、1. の、議論が行われていない、のが いちばんつらいところだな、と感じています。 （以前に台灣で、同じように海上にも及んでしまう公園が設定されて、 せめて近海くらいで止めよう、という編集が行われたと記憶しています。 たぶんこれ。 https://www.openstreetmap.org/relation/4074850/history ） このままゆくと、僕は、このかたの編集（と、たぶん同様の国立公園編集をされているもの）を すべて、ライセンス互換性の齟齬から、消さざるを得なくなっていまいます。 僕は、それをしたくありません。 議論をしたいです。 ご意見をお待ちしています。 -- Satoshi IIDA mail: nyamp...@gmail.com javascript:_e(%7B%7D,'cvml','nyamp...@gmail.com'); twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org javascript:_e(%7B%7D,'cvml','Talk-ja@openstreetmap.org'); https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org javascript:_e(%7B%7D,'cvml','Talk-ja@openstreetmap.org'); https://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com javascript:_e(%7B%7D,'cvml','nyamp...@gmail.com'); twitter: @nyampire -- Satoshi IIDA mail: nyamp...@gmail.com javascript:_e(%7B%7D,'cvml','nyamp...@gmail.com'); twitter: @nyampire -- Toshikazu SETO, Ph.D. Center for Spatial Information Science University of Tokyo e-mail: toss...@csis.u-tokyo.ac.jp t...@lt.ritsumei.ac.jp / toss...@gmail.com URL: http://i.csis.u-tokyo.ac.jp/ 瀬戸寿一 東京大学空間情報科学研究センター・特任助教 ___ Talk-ja mailing list Talk-ja@openstreetmap.org
Re: [OSM-ja] 国立公園 (national_park) の編集について
ならのにしむらです 下記についてですが，ライセンス的にOSMに投入できるかどうかという議論以前に，インポートのガイドライン・手続きを介していないインポートは大変問題であるように思います http://wiki.openstreetmap.org/wiki/JA:インポート/ガイドライン ひとまず削除してから，それでもなお必要なデータということであれば，インポートに関するwikiの整備，ローカルコミュニティにおける議論，データ所有者からのライセンス上の承認を得ること，imports MLへのレビュー依頼，などの手順を踏んで，その後インポートを行う必要があると思います． この面からも瀬戸さんが提起したリバート案に賛成です． 2015/08/20 22:12、Toshikazu SETO toss...@gmail.com のメール： 瀬戸です。 正確にはオープンデータの類とは異なるデータセットであること（OSMのライセンスとは相容れないので、積極的に残す理由が現状ない） 研究で以前利用したこともあるのですが、本データが他のデータに勝るような正確性があるかというと、個人的な感触ではそうでもない点 から、特にデータインポートに関する議論を経ずに行われた作業に対してライセンス的に疑念があるものであれば、リバートすることが現実的でないかと思います。 2015年8月17日月曜日、Satoshi IIDAnyamp...@gmail.comさんは書きました: いいだです。 遅くなってしまいましたが、変更セットへのコメントを行っています。 https://www.openstreetmap.org/changeset/33048672 2015年8月11日 9:22 Satoshi IIDA nyamp...@gmail.com: いいだです。 ありがとうございます。 ライセンス互換性、個別の許可の取得 なるほど、個別の許諾交渉というのはひとつの手かもしれませんね。 環境省生物多様性センターさんに知り合いはいないので、 正面からあたってみるしかないかんじですが、、、 OSMFJとして行うか、個人として行うかは別として、ちょっと検討してみます。 （事後報告になっちゃうのはかなり厳しい気がしています） 政府標準利用規約をCC-BY互換に改定 はい、議論の俎上にあがる可能性が高いと伺っています。 ただ、ライセンス変更の結果がでるのは早くても今年度末かと思いますので、 待つのはちょっと厳しいかなぁ、とも感じています。 # CC-BY 4.0互換（2.1 JPではなく）になると、 # OSMでも利用できる可能性が高くなることもあり、 # 委員会での議論の行方は僕もたいへん注目しています。 トレースについて これも、調製をおこなった地図（作品）の利用にあたるかと思いますので、 調製された主体に確認が必要ですね。環境省さんかぁ。。。 海上の公園について 明確に議論がされたことは無いと思っています。 海岸線を1km延伸した海上部分も含めたほうがよい、ということで、納得しました。 できれば、インポート作業されたかたの意見も伺いたいなぁ。。。 2015年8月9日 17:42 centree oki_aic...@yahoo.co.jp: centree です。 私も詳しくありませんが… (1) ライセンスについて 政府標準利用規約というのがあるのですね。恥ずかしながら存じ上げませんでした。 http://www.biodic.go.jp/trialSystem/info/nps.html この辺のデータをコンバートして投入したいなら、確かに量も量ですし、OSMFJで許諾をとって頂いておいた方が安心かと思います。 OSMはそんなに黒い（？）要途を主な目的としてはいないと思うので、交渉や問い合わせは可能なのではないかと思いますが 確かにOSMに投入すると、後の用途は限っていませんので『公序良俗』に照らし合わせ、どのように判断がでるかは未知数ですね。 ちなみに、もし、上記のような生のデータではなく、 http://www.env.go.jp/park/yakushima/intro/files/area_3.pdf のようなP DF媒体からのトレースということになると、背景画に承認番号付きの地理院の地図が使われているので 地図タイルのトレースのみが許諾されているOSMへの投入はNGなのではないかなと思います。 (2)海上の公園について 国立公園の資料を見ると、海上もしっかり公園と称されているようなので、基本的には含めるべきなのかなと思います。 ただ、瀬戸内海国立公園なんかは範囲も広く、なかなかスケールの大きい作業になりそうですが… centree - Original Message - From: tomoya muramoto muramototom...@gmail.com To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2015/8/9, Sun 15:19 Subject: Re: [OSM-ja] 国立公園 (national_park) の編集について muramotoです。 インポートやライセンス関係には不案内なため、類似の経験をお持ちの方のご意見を待ちたいところですが、ざっと調べた上での所感です。 (1)ライセンスについて ・環境省生物多様性センターのライセンスは、ご指摘のとおり、利用用途に制限があるようです(「公序良俗」制限)。一方でODbLには利用用途に制限がないようです。ODbLのほうが緩いので、使えないのではないかと思います。 ・そのため、データをOSMで利用する場合は、個別に許諾を得る必要があると思います。例えば、国土地理院はGSImaps利用のライセンスで「公序良俗」の制限を課していますが、大変有難いことにOSMFJの方が個別に許諾を取っていただいたとのことなので、私は安心してデータを利用させていただ いております。 http://wiki.openstreetmap.org/wiki/JA:GSImaps ・もしくは、政府標準利用規約をCC-BY互換に改定しようという動きもあるようなので、その結果を待つのもひとつの手だとは思います。 https://www.kantei.go.jp/jp/singi/it2/densi/kwg/dai2/siryou2.pdf (細かいですが、環境省生物多様性センターのライセンスは政府標準利用規約（第1.0版）に準拠のようです。) (2)海上の公園について ・海上が国立公園として指定されている(海域公園地区または普通地域)のであれば、海上も範囲に含めるべきだと思います。国立公園では、海岸から1kmまで「普通地域」として指定されているようです。 ・過去の議論において、海上を含めるのは不都合であるという結論に達したのであれば、それに従って良いと考えますが、個人的には議論の流れを知りたいとは思います。 2015年8月8日 22:31 Satoshi IIDA nyamp...@gmail.com: いいだです。 国立公園のデータについて、インポート、あるいはトレースを行っているような形跡が見受けられました。 例えば、この編集です。 https://www.openstreetmap.org/changeset/33048672 この編集には、いくつかの問題があります。 1. 議論がされていない talk-ja, imports、どのメーリングリストにも、事前の相談が行われていません。 2. ライセンスの互換性 ライセンスを確認すると、政府標準利用規約(ver. 1.1)のようです。 しかしながら、その互換性については、いまだ議論が行われておらず、 インポート作業を行うには、法的な互換性が保たれていることが必要かと思っています。 （いわゆる、3条ア 公序良俗条項、のところがメインです） 逆に言えば、ここが担保されていれば、多くのデータが利用可能になります。 議論をし、互換性について議論したいです。 ■方針について データ自体については、有用なデータだと感じていますので、 できれば使い続けたいと考えています。 ただし、海の上にまで公園の範囲が及んでしまうなど、 疑問点がいくつかありますので、1. の、議論が行われていない、のが いちばんつらいところだな、と感じています。 （以前に台灣で、同じように海上にも及んでしまう公園が設定されて、 せめて近海くらいで止めよう、という編集が行われたと記憶しています。 たぶんこれ。 https://www.openstreetmap.org/relation/4074850/history ） このままゆくと、僕は、このかたの編集（と、たぶん同様の国立公園編集をされているもの）を すべて、ライセンス互換性の齟齬から、消さざるを得なくなっていまいます。 僕は、それをしたくありません。 議論をしたいです。 ご意見をお待ちしています。 -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire -- Toshikazu SETO, Ph.D. Center for Spatial Information Science University of Tokyo e-mail: toss...@csis.u-tokyo.ac.jp / toss...@gmail.com URL: http://i.csis.u-tokyo.ac.jp/ 瀬戸寿一 東京大学空間情報科学研究センター・特任助教 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org
Re: [Talk-it] josm e server api
Domanda stupida, josm è aggiornato all'ultima stabile? Magari una re installazione sistema tutto. Il 20/ago/2015 12:17, emmexx emm...@tiscalinet.it ha scritto: Il 08/20/2015 11:59 AM, Simone Cortesi scrisse: a me JOSM funziona regolarmente non hai impostato per sbaglio un proxy? Direi di no. l'URL da te citato è la root dell'API, e da sempre da un 404. Quando avvio josm appare il seguente messaggio: JOSM tried to access the following resources: https://josm.openstreetmap.de/josmfile?page=Styles/Highway_Nodesstyle https://api.openstreetmap.org/api/capabilities https://josm.openstreetmap.de/maps https://josm.openstreetmap.de/wiki/StartupPage but failed to do so, because of the following network errors: java.net.SocketException: Network is unreachable It may be due to a missing proxy configuration. Would you like to change your proxy settings now? Vado nella configurazione del proxy ed e' impostato No proxy. Nella stessa scheda di configurazione della connessione c'e' spuntato: Use the default OSM server URL (https://api.openstreetmap.org/api) Prima che scrivessi qui c'era un altro valore (stupidamente non lo ho segnato) ma l'errore c'era lo stesso. Allora ho spuntato l'opzione di cui sopra. ciao maxx ___ 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] stop deleting abandoned railroads
On 20/08/15 14:06, moltonel 3x Combo wrote: On 19/08/2015, Lester Caine les...@lsces.co.uk wrote: 98% of the history that we are looking to manage properly is currently existing in OSM. All that is needed is to add start dates to the bulk of the existing data. What do you do when a road gets upgraded, widened, straightened, renamed, or some combination thereof at various points in time ? start/end_date tags are way too crude, they can't capture any evolution (as opposed to construction/demolition) of the real world, making their use very limited. The same applies today to mapping the fine detail of what you describe. Many of the footpaths around here have been improved and expanded but there is currently no easy way to map the current state ... but simply adding a date when the footpath first appeared is better than nothing, and that has nothing to do with OHM, it is simply adding current data to the current map. The SMALL amount of material that is a result of new development work invariably maps into currently existing objects. That's just not true, by definition new developments are new objects (and often a lot of old objects relegated to the past). And the amount of evolution in the real world is by no mean small. Some parts of the world are demolishing large areas of 'history' but on the whole, the increase in volume of currently valid data considerably outstrips the small amount of historic data it replaces. Insisting that this data is only available for rendering purposes in a second database is just wrong, and even worse, the 98% of the supporting data exists in OSM so why maintain a second copy of it. I would actually love to be able to map the past in OSM. But if all you have to offer me is start/end tags and some renderer/editor workarounds, I'll say no thanks. Totally agree! The current problem *I* have is that the OHM is a complete waste of space since the material I have a growing amount of is the start_date for the CURRENT objects on OSM. All that I am allowed to add is that start and end date tag, but YES there is room to improve the model ... but it's not just improving management of object evolution, it's adding EXISTING fine detail to current objects. To me OHM's value is not so much in its data as in being a sandbox to experiment with tooling to map the past, which can eventually be merged back into OSM. I suppose the OSM data model itself has to be modified to support a nonlinear history, but this is tricky. There is no point my even looking at OHM at the present. Unless I can import all of the existing data from OSM since that is what I want to work on. Along with managing the evolution of the road system in the UK, where very few roads get 'abandoned', while the railway system has not survived quite as well. Just up the road from here one of the military depots is now a new housing development. We have the existing railway structure and can track it's destruction as the new development progresses, and the historic view is already well mapped so there is no work needed to record that ... ONLY tag it's end_date as sections get removed, leaving the elements that are to be retained since restoration of the line down to Broadway is still a potential target. The Broadway bypass was built with a railway bridge 'capable of handling electrification' despite the fact that there is no track bed currently. The route still forms part of the 'protected' network which may be required in the future. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-lv] valmieras un tukuma robežu maiņa
Reku pats grozitais likums. http://m.likumi.lv/doc.php?id=255698 On Thu, Aug 20, 2015, 16:13 Rich ric...@nakts.net wrote: http://www.vzd.gov.lv/lv/jaunumi/zinas/mainitas-administrativas-robezas-valmierai-un-beverinas-engures-tukuma-novadiem/ vai šīs izmaiņas viegli iezīmēt ? tādas precīzas jaunās robežas nesapratu -- Rich ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
[Talk-br] Workshop OSM na UFBA dia 26 de Agosto
Oi, Vou fazer um workshop OSM durante o evento ihacLab-i https://www.facebook.com/ihaclabi/photos/gm.443016092552552/1511945275763419/?type=1theater na UFBA o dia 26 de manhã. Se alguém conhece pessoas que seriam interessadas para participar, aparentemente tem 30 vagas. Durante esse tempo curto, vou aprender as pessoas a editar com o computador e também com o OSMAnd, configurando o Bing Earth como mapa subjacente para adicionar POIs com alta precisão. Não sei se todo mundo aqui conhece, mas é um jeito muito bom para adicionar (muitos) POIs. Olhe ai por exemplo: https://www.openstreetmap.org/#map=18/-12.99796/-38.52310 Se outras pessoas são interessadas para um encontro em Salvador para bater um papo ou organizar uma oficina... Pode ser em relação ao mapeamento humanitário, a técnicas de mapeamento no terreno e organização de equipes, à reutilização de dados OSM num SIG com tradução/transformação dos atributos, etc. Abraços, Severin ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] RES: Reunião Periodica - OSM Brasil Peter Krauss
Peter, Concordo com o que você o falou (*A ECT é a princípio uma aliada do OSM...*) e digo mais, o OSM é (e poderá de tornar de fato) um poderoso aliado da ECT. Além disso, o diálogo, como você disse *[*Ainda não entremos com a ação (nós = grupo de interesse independente da OSM) pois acreditamos na conscientização e no diálogo, que em seguida, *gerariam de fato uma parceria]. *será a forma mais fácil para que essa importante base de dados seja disponibilizada livremente. Fixo à disposição. Bom dia Ivaldo! A ECT é a princípio uma aliada do OSM, assim como o IBGE, as prefeituras, etc. O que tenho percebido das conversas paralelas sobre o problema da abertura do CEP é que o brasileiro em geral acredita na seriedade e tem em boa conta os serviços prestados pelos Correios. O entrave que se criou foi com a esfera burocrática da ECT, e a percepção que tivemos é que, mesmo nas diretoriais locais da ECT não há um posicionamento contra o CEP aberto. Havia sim ignorância, desconhecimento do assunto, e estamos buscando mostrar para os administradores da ECT a relevância do CEP aberto... Mesmo entre os administradores e advogados parece um problema bobo e pouco relevante, já que a maioria das pessoas estaria satisfeita com obuscacep.correios.com.br ... O detalhe com o qual nos debatemos é jurídico, e seria resolvido por uma Ação Civil Pública, tal como foi aplicada à ABNT em caso similar http://www.pessoacomdeficiencia.gov.br/app/normas-da-abnt/termo-de-ajustamento-de-conduta. Ainda não entremos com a ação (nós = grupo de interesse independente da OSM) pois acreditamos na conscientização e no diálogo, que em seguida gerariam de fato uma parceria. Seria ótimo ter um interlocutor da ECT aqui na Lista (!), e melhor ainda se você pudesse nos ajudar a esclarecer e dialogar com as outras pessoas da ECT... É uma trabalho de formiguinha, de corpo-a-corpo, mas pode ser muito mais produtivo do que entrar com uma ação jurídica. PS: a boa notícia que comentamos antes é que o Thierry, em nome da OSM, está colhendo os frutos do diálogo que ele fomentou em Brasília, junto à diretoria geral da ECT. O diálogo é relevante e dá resultado! Agradeço desde já por estar escrevendo (!) e sua por sua disposição de ajudar a OSM. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-it] Servizio immagini vettoriali stampabili mappa OSM + traccia GPS?
Ciao, vorrei inserire delle mappe OSM in dei documenti pdf e perciò ho letto http://wiki.openstreetmap.org/wiki/OSM_on_Paper ma ho l'esigenza di inserire anche delle tracce gps che vorrei fossero evidenti sulla mappa, la mappa mi piacerebbe fosse in stile OpenCyleMap o comunque un rendering che mostri le linee dei rilievi. Il servizio che si avvicina di più che ho trovato è http://inkatlas.com/ ma io vorrei una sola immagine, meglio se vettoriale e purtroppo la traccia su inkatlas è poco visibile. Qualcuno conosce qualcosa che si avvicini alle mie esigenze (dati OSM, visualizzazione tracce, vettoriale, meglio se è possibile scegliere fra vari rendering)? Grazie. Ciao, Mirco -- View this message in context: http://gis.19327.n5.nabble.com/Servizio-immagini-vettoriali-stampabili-mappa-OSM-traccia-GPS-tp5852756.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
[Talk-lv] valmieras un tukuma robežu maiņa
http://www.vzd.gov.lv/lv/jaunumi/zinas/mainitas-administrativas-robezas-valmierai-un-beverinas-engures-tukuma-novadiem/ vai šīs izmaiņas viegli iezīmēt ? tādas precīzas jaunās robežas nesapratu -- Rich ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-us] New MapRoulette challenge - fix railway crossings
On 8/4/2015 4:59 PM, Martijn van Exel wrote: Also, please even if you see the crossing rendered, do go in and check, because I have seen more than once that the crossing node is not a shared node between way and rail. (Hint, use 'j' to join node to way and 'm' to merge nodes that are (almost) on top of each other.) I noticed something interesting about JOSM - if I select an intersection that may or may not have 2 duplicate nodes, in some cases where there were 2 nodes, the JOSM 'M' command has no effect the first time. Now I always watch and try again if the merge was ignored. But that can be another post-challenge fixup - duplicate nodes on rail crossing. Other notes: Please don't (C)ombine sections of railway unless there is a good reason. I don't know if anyone is combining currently, but there was a long span across South Dakota spanning 2 counties and 400 nodes which was shifted (perhaps to correct a local problem). Mappers fixed various crossings, and the long way was shifted 2 more times. I finally just manually reviewed and fixed the entire shifted way. https://www.openstreetmap.org/changeset/33235552 ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] stop deleting abandoned railroads
On 19/08/2015, Lester Caine les...@lsces.co.uk wrote: 98% of the history that we are looking to manage properly is currently existing in OSM. All that is needed is to add start dates to the bulk of the existing data. What do you do when a road gets upgraded, widened, straightened, renamed, or some combination thereof at various points in time ? start/end_date tags are way too crude, they can't capture any evolution (as opposed to construction/demolition) of the real world, making their use very limited. The SMALL amount of material that is a result of new development work invariably maps into currently existing objects. That's just not true, by definition new developments are new objects (and often a lot of old objects relegated to the past). And the amount of evolution in the real world is by no mean small. Insisting that this data is only available for rendering purposes in a second database is just wrong, and even worse, the 98% of the supporting data exists in OSM so why maintain a second copy of it. I would actually love to be able to map the past in OSM. But if all you have to offer me is start/end tags and some renderer/editor workarounds, I'll say no thanks. To me OHM's value is not so much in its data as in being a sandbox to experiment with tooling to map the past, which can eventually be merged back into OSM. I suppose the OSM data model itself has to be modified to support a nonlinear history, but this is tricky. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] stop deleting abandoned railroads
On 20/08/2015, Russ Nelson nel...@crynwr.com wrote: moltonel writes: When they show up, we can have a discussion. In the meantime, I'm here, and many other mappers map abandoned and dismantled railways, and we would like to NOT HAVE YOU FRICK WITH OUR STUFF. Please don't shout and curse, it just kills the debate. Your defense of railway=* mapped thru buildings of a housing estate is something that I (and AFAICT most of the community) cannot agree with, so that topic has reached a dead-end and I'll stop discussing it. Hopefully someday we'll get a proper way to map in the 4th dimention in OSM (hint: OHM is not good enough yet). In the meantime, if I happen to be mapping somewhere and see an abandoned/dismantled railway going thru houses like in your perfect example of how a railway should be mapped, I'll delete it. Regards. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-es] CheckAutopista2
- Voy a añadir tooltips para los botones y igual algún texto explicativo sobre cómo usar la herramienta. - Intentaba no tener que traducir la página y usar solamente iconos. Pero como voy a añadir tooltips y igual algún texto mas, tendré que traducirla como hice con la versión anterior. - He echado un vistazo a los datos de OSM de la M-50 y no parece que haya una relación para esa carretera. Eso es imprescindible para poder mostrarla en CheckAutopista. k1wi El 20/8/2015, a las 10:30, Luis García Castro lui...@gmail.com escribió: El 19 de agosto de 2015, 10:52, k1wi k1wi...@gmail.com escribió: Os animo a probarlo y comentarme que os parece. Comentarios breves y rápidos: * Incluso conociendo la versión anterior y sabiendo qué pretende la herramienta... he echado de menos tener tooltips o similar en cada botón/acción. Algunas no son evidentes viendo solamente el icono. * No hay muchos textos, pero sería genial si pudieras hacer la web multi-idioma. * Por algún motivo, supongo que relacionado con los datos, no me detecta la M-50... lo miraré luego desde casa Enhorabuena de nuevo, es una herramienta muy útil :-) -- Luis García ___ 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-us] Tagging National Forests
On Thu, Aug 20, 2015 at 10:22 PM, stevea stevea...@softworkers.com wrote: John Firebaugh writes: The political boundaries of US National Forests should not be tagged landuse=forest unless the entirety of their area is land primarily managed for timber production. I venture to assert that this is not true for *any* of the National Forests. Here are some examples of areas within National Forests that are not primarily managed for timber production. OK, so say so where so. (Tag in OSM accordingly). If you wish to subtract from the polygon areas which you are absolutely certain no timber production is allowed or possible, go for it. It wouldn't be correct to exclude areas where no timber production is allowed or possible from the multipolygon indicating the political boundaries of a National Forest. That would mark such areas as not included inside the boundaries, when in fact they are included. There should be (at least) two separate entities in the database. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tagging National Forests
The political boundaries of US National Forests should not be tagged landuse=forest unless the entirety of their area is land primarily managed for timber production. I venture to assert that this is not true for *any* of the National Forests. Here are some examples of areas within National Forests that are not primarily managed for timber production. http://julialanning.com/files/2011/09/A-Plains-Rainier-RSZ.jpg This is a pumice field in the Plains of Abraham near Mt. St. Helens. It's not producing timber, and is not being managed to so as to do so any time soon. Mount St. Helens National Volcanic Monument lies within Gifford Pinchot National Forest. https://upload.wikimedia.org/wikipedia/commons/2/22/6507-ShastaLakeFull.jpg Shasta Lake, part of Shasta-Trinity National Forest, is the largest man-made lake in California -- 4,552,000 acre·ft at full pool, though significantly diminished as a result of the drought. None of the lake area is being primarily or even partially managed for timber production. https://upload.wikimedia.org/wikipedia/commons/9/91/Mendenhall_Glacier_%28Winter%29.jpg It won't be possible to produce timber in the area currently covered by the Mendenhall Glacier, in Mendenhall Glacier Recreation Area, a unit of the Tongass National Forest, until global warming significantly advances its melting. It may be sooner than we think, but not today! http://timberlinetrails.net/sitebuilder/Photos/Whitney/EastFaceRoute.jpg The East Face of Mt Whitney, in Inyo National Forest, features one of the world's classic rock climbs. The route lies entirely above 13,000 feet, and climbers on it will be hard pressed to find any substantial vegetation at all, let alone anything that could be used to produce timber -- or even firewood. Even if you happen to believe that personal wood-gathering for building a fire constitutes timber production -- and I, like Frederik, think that this definition is patently ridiculous -- there are many areas within National Forests where it's impossible to do so. We should be tagging the areas within them, where timber production is happening or at least possible, as landuse=forest, not the entire political boundary. On Thu, Aug 20, 2015 at 9:57 AM, stevea stevea...@softworkers.com wrote: On 08/19/2015 07:25 PM, stevea wrote: This isn't extreme. Your backyard activity is consistent with the definition of a forest: a land which is used for the production of wood/lumber/timber/firewood/pulp/et cetera. Frederik, Frederik, Frederik...where do I begin?! According to our wiki, which I DO follow when there is ambiguity or any question about what or whether I should map something, landuse=forest is used to mark areas of land managed for forestry. As I have said here before (recently), this is EXACTLY, PRECISELY what a USFS national forest is. If we change what tags mean in this project, we ought to have a better set of tags to use instead, and we are some distance from that. There is a problem with this definition; it is too broad. I use the wiki definition I note above. Consistently. Even on polygons from local zoning/cadastral data marked as Timber Production in my county. Whether there is active felling of trees or not. The heart of the matter here is quite likely that the wiki definition for forest is overloaded: OSM uses at least four different interpretations as the wiki outlines. A solution to this problem might start with consensus-based re-definition, followed by consistent (worldwide) application of the new method, and rendering support to see what we have done. That's a lot of work we ought to get started doing. Even the seabed can fulfil some of these uses and we don't want to tag forests in the sea. What the heck? I know of no trees growing on the seabed! (Although if there were an odd tree, say near the shoreline of the sea, I agree with a natural=tree node there -- but I don't think I've ever seen one). This definition of a forest is unsuitable for OSM and should not inform our tagging. (Luckily the Wiki, which is not always reliable on these issues, says: A forest or woodland is an area covered by trees., and not: A forest is an area where you could potentially find something to light a fire with.) Please don't twist what I say, conflate my meanings or read into what I have written, as it appears you have. What I have done is apply the wiki definition (area of land managed for forestry) to USFS polygons. Stick to that and tell me I'm wrong, because I don't believe I am by that definition and application. There is also a problem with your interpretation of this already-unsuitable definition; you say that if land yields wood for any reason, it is used in the production of wood. But I see a difference here between scavenging and agriculture. Just because there's wild berries somewhere, doesn't make the area an orchard. Just because you are legally allowed to pick up a branch that
Re: [Talk-us] Tagging National Forests
-Original Message- From: stevea [mailto:stevea...@softworkers.com] Sent: Thursday, August 20, 2015 11:22 PM To: talk-us@openstreetmap.org Cc: John Firebaugh Subject: Re: [Talk-us] Tagging National Forests Well, perhaps we have a happy compromise here. Tell you what: I'll start with the assumption that a forest should be tagged forest. (That's fair, and/or I'm listening to your alternative proposition). WHEN, WHERE and IF you know a particular area to be expressly NOT a forest, you are perfectly welcome to exclude that subset from said polygon. I'm fine with that. SteveA California Hello, I have another suggestion, how about we do not assume. We seem to be in agreement (vast majority) about boundary=protected_area being the only tag that should for sure be applied to every National Forest. Please don't tag Pike National Forest with landuse=forest because some subsets have already been tagged (where you can see timber harvesting 'scars' in the imagery) and I have ground verified - by seeing signs (sorry don't have a picture) - but (paraphrased) they say fuel wood gathering by permit only and if you'd like you can contact the districts for the designated areas where it is allowed but shouldn't be mapped the other way around because it is a very small subset of Pike. Cheers, =Russ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Am 20.08.2015 14:20, schrieb Christoph Hormann: On Thursday 20 August 2015, Stephan Wolff wrote: kann jemand eine sinnvoll anwendbare Definition von künstlichen / menschengemachten Wasserflächen geben? Für stehende Wasserflächen: natürlich (also water=lake/pond): die Wasserfläche existierte schon vor dem Beginn menschlicher Eingriffe/würde ohne menschliche Eingriffe existieren. Für Wasserläufe: natürlich (also waterway=river/stream und ggf. waterway=riverbank bzw. water=river für das Polygon): es hat vor den menschlichen Eingriffen einen Wasserlauf gegeben, der im Verlauf und in seinem Einzugsgebiet dem jetzigen ähnelt. Bei großen Flüssen und Seen ist offensichtlich oder zumindest leicht zu ermitteln, ob sie vom Menschen geschaffen wurden. Aber gerade bei den kleinen Gewässern, um die es hier geht, ist die Unterscheidung nach diesen Kriterien sehr schwer. Wer hat schon Karten aus der Zeit der ersten Kultivierung? Welche kleinen Wasserläufe dieses Gebiets sind natürlich? http://www.openstreetmap.org/#map=13/54.3349/9.4072 Die Bezugnahme auf die Vergangenheit vor den menschlichen Eingriffen ist natürlich im Sinne der Überprüfbarkeit etwas heikel. Das macht die Unterscheidung aber noch nicht generell sinnlos. Der historische Ansatz passt nicht zu OSM. In OSM wird generell der aktuelle Zustand erfasst. Soll man zwei aktuell gleiche Wasserläufe mit unterschiedlichen Tags erfassen, wenn einer einen natürlichen Vorgänger hatte? Wer die ganze Unterscheidung komplett abschaffen möchte sollte bedenken, dass dies den Nutzen der Daten insbesondere in wasserbaulich stark erschlossenen Gebieten enorm einschränken würde. Welche Anwendungen braucht die Unterscheidung nach der Entstehung des Gewässers? Für welche Anwendungen würde es eine enorme Einschränkung bedeuten? Um auf Übersichtskarten nur Große Flüsse darzustellen fehlt dagegen eine Unterteilung in kleiner Fluss, großer Fluss und Strom wie im ersten Diagramm im Wikipediaartikel Fließgewässer. https://de.wikipedia.org/wiki/Flie%C3%9Fgew%C3%A4sser Aktuell werden kleine Wasserläufe ohne erkennbares System als ditch, drain oder stream bezeichnet. Schlimmer kann es nicht werden. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Graz+Innsbruck: »Schiene und Straße wurden getrennt«
On 20.08.2015 11:18, Jonathan Gallagher wrote: - Wo sich zweispurige Tramgleise mit dem Straßenverkehr diesselbe Spur teilen, werden die zwei Gleise einzeln gemappt (mittig der Gleise) und die Straße als Kante dazwischen (siehe zb. Taborstraße, Wien [2]) Das ist in Wien kein Konsens, sondern das Werk einer einzigen Person (Railjet). In der Mailingliste, auf Openstreetbugs und in den Map Notes stießen seine Änderungen auf heftige Kritik, und soweit ich mich erinnern kann, hat kein einziger sie gutgeheißen. Nicht mal er selber, denn er hat sich an keinen Diskussionen beteiligt. Ein Problem des separaten Mappens ist, dass es dann in der Karte so aussieht, als läge die Fahrbahn zwischen den Gleisen; in Wahrheit ist es aber eher umgekehrt. Und das ist nicht nur ein Darstellungsproblem. Es kann dir passieren, dass der Router dir zum Queren der Straße sagt: Überquere die Schienen, dann eine Straße, dann nochmals Schienen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] quand Google court après OSM
De : osm.sanspourr...@spamgourmet.com osm.sanspourr...@spamgourmet.com Certains municipalités allemandes proposaient déjà un calcul de l'ensoleillement en se basant sur les données OSM (et je pense de la photo aérienne pour les calculs des orientations des toits). Voici que G... s'y met. Jean-Yvon Source : Futura sciences via [Rezo-actu] http://www.futura-sciences.com/magazines/high-tech/infos/actu/d/technologie-sunroof-google-veut-nous-aider-passer-solaire-59420/ Salut, Ca peut etre bien aussi de preciser cela en commentaire de l article si tu as un compte chez futura-sciences Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] The Proposed Great Colour Shift
The humanitarian style uses a good compromize to represent the hierarchy of roads. The blue is replaced by a violet color. This maitains a larger color palette to represent the hierarchy of roads. And, importantly, the yellow color is kept for tertiary roads. I also think that it is important to color the tertiary roads to show a good hierarchy of roads in rural areas. Pierre De : Jóhannes Birgir Jensson j...@betra.is À : talk@openstreetmap.org Envoyé le : Jeudi 20 août 2015 15h37 Objet : Re: [OSM-talk] The Proposed Great Colour Shift Þann 20.8.2015 18:36, skrifaði Frederik Ramm: Your use case of easily recognizable tertiary road in sparsely populated regions is valid, but perhaps it is niche enough to accept that it need to be served by the main map style. I'm fairly certain that the rural regions of the world are not a niche but where we are sorely lacking in data and where our growth in Africa (for example) will come. Having done data quality checks on settlements of the world thousands of them are still just a name on the map with no road connections and there tertiary roads will be needed to go. I'm not averse to red/yellow taking over personally but the expense is too great for me at the moment. We need to find a way to make tertiary still recognizable. --JBJ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-fr] quand Google court après OSM
Certains municipalités allemandes proposaient déjà un calcul de l'ensoleillement en se basant sur les données OSM (et je pense de la photo aérienne pour les calculs des orientations des toits). Voici que G... s'y met. Jean-Yvon Source : Futura sciences via [Rezo-actu] http://www.futura-sciences.com/magazines/high-tech/infos/actu/d/technologie-sunroof-google-veut-nous-aider-passer-solaire-59420/ Avec Sunroof, Google veut nous aider à passer au solaire http://www.lefigaro.fr/ Google a en projet un service, qui a pour l'instant le nom de Sunroof, destiné à déterminer si le toit d'un bâtiment conviendrait pour des panneaux solaires. Grâce à Google Earth, on pourrait évaluer le potentiel énergétique d'une toiture en tenant compte de son exposition et estimer les économies réalisables. Le 19/08/2015 à 13:27 - Marc Zaffagni, Futura-Sciences ** ***Déjà fournisseur d’accès Internet par fibre optique, Google pourrait ajouter une nouvelle corde à son arc en proposant de l’installation de panneaux solaires. Le géant américain n’a encore rien annoncé, mais il vient de faire un premier pas dans cette direction avec son projet Sunroof. * Deuxième pays le plus pollueur après la Chine, les États-Unis veulent s’engager dans un ambitieux plan de réduction des émissions http://www.futura-sciences.com/magazines/matiere/infos/dico/d/physique-emission-389/ de CO_2 afin de lutter contre le réchauffement climatique http://www.futura-sciences.com/magazines/environnement/infos/dico/d/climatologie-rechauffement-climatique-13827/. Avec la conférence de Paris sur le climat http://www.futura-sciences.com/magazines/environnement/infos/dico/d/climatologie-climat-13771/ (COP 21 http://www.cop21.gouv.fr/fr) en ligne de mire, le président Barack Obama vient d’en faire son ultime combat avant le terme de son mandat qui s’achèvera l’année prochaine. /« Il n'y a pas de défi qui pose une plus grande menace pour notre avenir et pour les générations futures que le changement climatique http://www.futura-sciences.com/magazines/environnement/infos/actu/d/climatologie-changement-climatique-role-doivent-jouer-scientifiques-58567/ »/, a-t-il déclaré en annonçant un programme qui vise à réduire de 32 % les émissions des centrales thermiques nord-américaines d’ici 2030. Les énergies renouvelables http://www.futura-sciences.com/magazines/environnement/infos/dico/d/energie-renouvelable-energie-renouvelable-6634/ sont au cœur de ce plan, en particulier le solaire et l’éolien. Si l’action est évidemment louable, elle représente aussi un attrait économique considérable. Le marché de l’énergie solaire est en plein essor et de nouveaux acteurs s’y intéressent de près. Ainsi, le constructeur de voitures électriques http://www.futura-sciences.com/magazines/environnement/infos/dico/d/energie-renouvelable-voiture-electrique-13758/ Tesla http://www.futura-sciences.com/magazines/matiere/infos/dico/d/physique-tesla-367/ a-t-il récemment dévoilé sa Tesla Powerwall http://www.futura-sciences.com/magazines/environnement/infos/actu/d/energie-renouvelables-tesla-lance-batterie-domestique-pour-transformer-energie-mondiale-58271/, une batterie domestique qui peut stocker l’électricité fournie par des panneaux solaires ou le réseau électrique http://www.futura-sciences.com/magazines/maison/infos/dico/d/maison-reseau-electrique-10888/. Comme d’autres géants de la high-tech, Google http://www.futura-sciences.com/magazines/high-tech/infos/dico/d/internet-google-3987/ est aussi très sensible aux questions environnementales et aux énergies renouvelables http://www.google.com/green/energy/#power. Et la firme californienne vient de lancer un nouveau projet nommé Sunroof http://googlegreenblog.blogspot.fr/2015/08/project-sunroof-mapping-planets-solar.html qui préfigure peut-être de grandes ambitions… Voici à quoi ressemble le projet Sunroof. Les personnes habitant dans l’une des trois régions pilotes aux États-Unis n’ont qu’à entrer leur adresse afin d’obtenir une vue aérienne de leur maison accompagnée d’une évaluation du potentiel d’ensoleillement de leur toiture et des économies réalisables. Sunroof prend en compte plusieurs variables comme la météo locale et la présence d’arbres à proximité qui peuvent créer de l’ombre. © Google Voici à quoi ressemble le projet Sunroof. Les personnes habitant dans l’une des trois régions pilotes aux États-Unis n’ont qu’à entrer leur adresse afin d’obtenir une vue aérienne de leur maison accompagnée d’une évaluation du potentiel d’ensoleillement de leur toiture et des économies réalisables. Sunroof prend en compte plusieurs variables comme la météo locale et la présence d’arbres à proximité qui peuvent créer de l’ombre. © Google Sunroof calcule un bilan énergétique à l'année Le projet Sunroof se présente comme un outil censé aider les particuliers à évaluer l’intérêt qu’ils auraient à installer des panneaux solaires sur le toit
Re: [Talk-ca] Fwd: Ottawa, Canada import
I would think it's the parts that give them the power to revoke the license to use the data at any time. For it to be used in OSM, it has to be essentially surrendered to the map. When I joined two years ago, one of the stipulations was to specifically accept the licensing agreement of OSM which effectively had me surrender any and all edits to OSM. It would reserve the right to maintain, modify, delete and otherwise use any information that I inputted as their own. Which makes complete sense, else if I were to become vindictive, I could try to revoke my license and they would have to remove my edits, which is difficult and potentially damaging. Specifically, as Steward mentioned, Ottawa has the reserved the right of cancellation of access to the data: *The City may, in its sole discretion, cancel or suspend your access to the datasets without notice and for any reason, including anything which the City, in its sole discretion, believes is a breach of these Terms of Use or is otherwise unlawful or harmful to others. In the event of cancellation or suspension, you will no longer be authorized to use or reproduce these datasets, and the City may use any means possible to enforce its decision. Such cancellation or suspension will not affect any person who has received the datasets from you and who is otherwise in compliance with these Terms of Use.* Basically, they can revoke the access and OSM will be forced to comply, removing the data and, as a result, any edits made that were based off that data. The other problem is the Liability clause. If they feel the use was a breach, then they may sue, indemnifying OSM and making it open to litigation. We, as users, don't have the right to do that. On Aug 20, 2015 4:59 PM, James james2...@gmail.com wrote: I got an email back from the guy handling the Licensing. Hi James, thank-you for the email. I’m not sure I understand the compatibility grid. Is there a particular issue you are concerned about? Note: we have plans to adapt the Open Government License Canada but have not been able to do that quite yet; however, there are few differences between the two, so if there’s a specific item you are concerned about it I might be able to shed some light on how we treat it. Thank-you, Robert Giggey --- What would be the specifics of our license (ODbL) incompatible with Ottawa-TOU? On Wed, Aug 19, 2015 at 10:14 AM, James james2...@gmail.com wrote: Email I got after I said I will be unable to use the data due to incompatible licensing: James, I’m going to forward this inquiry on to Robert Giggey. He is in charge of the Open Data program at the City. I must say, I am a little surprised that this interpretation is so restrictive. I personally was not aware of this. I will also follow-up with Robert in this regard. *-Stephen* Maybe, they just needed some education? P.s. thank you Stewart for the comparison tool! On Wed, Aug 19, 2015 at 9:23 AM, Stewart C. Russell scr...@gmail.com wrote: Hi James — What should I tell Stephen, to change the license for just OSM or in whole? For simplicity, they'd need to change the licence for everyone. A special carve-out for OSM alone would be fraught with problems. Ideally, they'd chose a licence that isunencumbered, like CC0 or PDDL. Any attempt to roll your own licence adds compatibility problems, and municipalities do love to keep those little clauses in that allow them to recall data. If you want to show Stephen how compatible and open the city's licence isn't, show him this: http://clipol.org/licences/16?tab=licence_compatibility It shows how Canadian municipalities all shared and tweaked licences, and inadvertently made them incompatible with everything. And they complain about why no-one uses their data. If they do want to change (great!), I know there are some folks on this list just itching for a roadtrip to the NCR to do some municipal education … cheers, Stewart ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca -- 外に遊びに行こう！ -- 外に遊びに行こう！ ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-at] Graz+Innsbruck: »Schiene und Straße wurden getrennt«
Hallo, das gegenteilige Problem hast du dann aber wenn du zum Beispiel ein Fußgängerrouting für Blinde implementieren willst, wo es kritisch ist, wie oft einem Gleise auf der Strecke begegnen werden. Nachverfolgung von Öffis in Echtzeit würde für eine saubere Darstellung auf einer Karte auch ein getrenntes Mapping voraussetzen. Prinzipiell sollte es möglich sein aufgrund der Öffi-Routenrelation die beiden Gleise all eine Verbindung interpretieren zu können und bei kurz aufeinanderfolgenden Kreuzungen von unterschiedlichen Ways nur beim ersten Mal einen Hinweis auszugeben. Prinzipiell ist zu sagen das es idR einfach sein wird detaillierte Daten runter zu rechnen und zu vereinfachen, als bereits durch den Mapper eine (subjektive) Vorfilterung vornehmen zu lassen und dann umständlich ungefähr-Annahmen heraus extrapolieren muss. Und wegen dem visuellen Aspekt: Für die Detail-Zoomstufen ibt es area:highway (http://forum.openstreetmap.org/viewtopic.php?id=26317). Da würden dann die Gleise wieder auf der Straße dargestellt werden. Bei höheren Zoomstufen fallen die beiden Gleisstränge dann visuell eh wieder zu einer Linie zusammen. In Linz sind die Gleise schon seit Jahren getrennt eingezeichnet und bis jetzt hat sich keiner daran gestoßen. Kann aber auch daran liegen, dass außer mir nicht recht viel andere in der Gegend regelmäßig aktiv sind :-) flaimo 2015-08-20 23:00 GMT+02:00 Friedrich Volkmann b...@volki.at: On 20.08.2015 11:18, Jonathan Gallagher wrote: - Wo sich zweispurige Tramgleise mit dem Straßenverkehr diesselbe Spur teilen, werden die zwei Gleise einzeln gemappt (mittig der Gleise) und die Straße als Kante dazwischen (siehe zb. Taborstraße, Wien [2]) Das ist in Wien kein Konsens, sondern das Werk einer einzigen Person (Railjet). In der Mailingliste, auf Openstreetbugs und in den Map Notes stießen seine Änderungen auf heftige Kritik, und soweit ich mich erinnern kann, hat kein einziger sie gutgeheißen. Nicht mal er selber, denn er hat sich an keinen Diskussionen beteiligt. Ein Problem des separaten Mappens ist, dass es dann in der Karte so aussieht, als läge die Fahrbahn zwischen den Gleisen; in Wahrheit ist es aber eher umgekehrt. Und das ist nicht nur ein Darstellungsproblem. Es kann dir passieren, dass der Router dir zum Queren der Straße sagt: Überquere die Schienen, dann eine Straße, dann nochmals Schienen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] The Proposed Great Colour Shift
On 20/08/15 02:16, Jóhannes Birgir Jensson wrote: The question really arises if this change is beneficial or not for the project. Many hours have gone into it and doing CartoCSS on all these zoom levels is not trivial. But this is a major shift on the front page of our website, a blow to those who use the default tiles through uMap or similarly and depend on the UK rainbow road style and makes life harder for mappers to visually confirm the type of road. Should this be a new, alternative style instead? That a UK version will appear is a simple fact. Ideally I would like anybody looking up OSM in the UK to be directed to that version. That may be a little more difficult to achieve, but removes the WTF provided by a more international solution? The problem of cause is that one has to switch to another server to get areas outside the UK unless we can provided a complete duplicate of the existing service ... retaining the current style base. For me, the new style is a pointless exercise since I NEED to retain a UK view of the data, and I am sure other countries would also prefer to retain their own road colour preferences so trying to provide an international style has a limited 'market'? If anything it simply drives us to provided more local styled services? I'm not going to object to the current plans, simply because I don't have to live with it, but I don't think that it IS the right development path for many reasons. Just what is the convention in the US, Russia or China? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] RES: Reunião Periodica - OSM Brasil Peter Krauss
Um tempo atrás entrei em contato com um mapeador aqui da região e descobri que ele trabalha nos Correios. Segue a resposta dele: Bom dia, tudo certíssimo, obrigado. Eu trabalho nos Correios de Alagoas, na área de codificação postal. Recebemos documentos das Prefeituras informando denominações ou alterações de denominações de logradouros, e é esta informação que estou passando para o OSM. O principal impedimento de compartilhar as informações que possuo é que estão em papel (mapas impressos onde anotamos as informações de CEP, distritos postais...). O segundo impedimento é que o compartilhamento em massa das informações que possuo (os Correios possui) depende de autorização da diretoria dos Correios. Por estar utilizando a base do OSM no QGis para criação de mapas (até o ano passado nossos mapas eram apenas os cedidos pelas Prefeituras e empresas de água e energia), fico trabalhando com estas ferramentas e aproveito para incluir alguma via ou denominações conforme observo na área que estou trabalhando. Espero ter esclarecido. Qualquer coisa é só entrar em contato novamente. E aí? Acredito que essa seja uma área nebulosa o fato dele mapear e trabalhar nos correios. Será que ele pode ser um aliado nessa briga? Marcio Aguiar Ribeiro 2015-08-20 9:28 GMT-03:00 Ivaldo Nunes de Magalhães ivald...@gmail.com: Peter, Concordo com o que você o falou (*A ECT é a princípio uma aliada do OSM...*) e digo mais, o OSM é (e poderá de tornar de fato) um poderoso aliado da ECT. Além disso, o diálogo, como você disse *[*Ainda não entremos com a ação (nós = grupo de interesse independente da OSM) pois acreditamos na conscientização e no diálogo, que em seguida, *gerariam de fato uma parceria]. *será a forma mais fácil para que essa importante base de dados seja disponibilizada livremente. Fixo à disposição. Bom dia Ivaldo! A ECT é a princípio uma aliada do OSM, assim como o IBGE, as prefeituras, etc. O que tenho percebido das conversas paralelas sobre o problema da abertura do CEP é que o brasileiro em geral acredita na seriedade e tem em boa conta os serviços prestados pelos Correios. O entrave que se criou foi com a esfera burocrática da ECT, e a percepção que tivemos é que, mesmo nas diretoriais locais da ECT não há um posicionamento contra o CEP aberto. Havia sim ignorância, desconhecimento do assunto, e estamos buscando mostrar para os administradores da ECT a relevância do CEP aberto... Mesmo entre os administradores e advogados parece um problema bobo e pouco relevante, já que a maioria das pessoas estaria satisfeita com obuscacep.correios.com.br ... O detalhe com o qual nos debatemos é jurídico, e seria resolvido por uma Ação Civil Pública, tal como foi aplicada à ABNT em caso similar http://www.pessoacomdeficiencia.gov.br/app/normas-da-abnt/termo-de-ajustamento-de-conduta. Ainda não entremos com a ação (nós = grupo de interesse independente da OSM) pois acreditamos na conscientização e no diálogo, que em seguida gerariam de fato uma parceria. Seria ótimo ter um interlocutor da ECT aqui na Lista (!), e melhor ainda se você pudesse nos ajudar a esclarecer e dialogar com as outras pessoas da ECT... É uma trabalho de formiguinha, de corpo-a-corpo, mas pode ser muito mais produtivo do que entrar com uma ação jurídica. PS: a boa notícia que comentamos antes é que o Thierry, em nome da OSM, está colhendo os frutos do diálogo que ele fomentou em Brasília, junto à diretoria geral da ECT. O diálogo é relevante e dá resultado! Agradeço desde já por estar escrevendo (!) e sua por sua disposição de ajudar a OSM. ___ 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-it] josm e server api
Il 08/20/2015 04:04 PM, Leonardo Frassetto scrisse: Domanda stupida, josm è aggiornato all'ultima stabile? Magari una re installazione sistema tutto. Stesso problema. Versione 8491 (appena riscaricata). ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk-fr] YoHours version 2 disponible
Vu que les retours sont positifs, je vais en parler sur la liste internationale, voir ce que l'on peut faire à ce niveau ;) Le 19/08/2015 21:13, osm.sanspourr...@spamgourmet.com a écrit : Superbe. À quand l'intégration dans nos éditeurs préférés et en lien sur http://overpass-turbo.eu/ ou OpenStreetMap quand on sélectionne un objet ayant cet attribut ? si je ne me trompe il suffit d'ajouter http://github.pavie.info/yohours/?oh= à la valeur en question. Au moins pour visualiser, pour récupérer la chaîne modifiée il faudrait récupérer l'adresse. Je sais y'a qu'à, faut qu'on, mais ne pas oublier la première phrase et ce serait bête de ne pas faire largement profiter de cet outil. Je vois que frem-eu pense comme moi ! Jean-Yvon ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] YoHours version 2 disponible
Je ne savais pas pour Pâques ;) C'est celui qui est défini dans la grammaire sur le wiki [1], il faudra poser la question à ceux qui l'ont écrite. Après les horaires à plus moins n jours d'un autre sélecteur temporel ne sont pas encore supportées (un jour peut-être ?), vu que leur usage semble plutôt limité. Cordialement. [1] https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification Le 19/08/2015 22:57, Philippe Verdy a écrit : en passant je note les fetes mobiles avec pâques qui tombe toujours un dilanche mais pas les autres dates calculees avec un nombre fixe de jours avant ou apres paques. de plus ce n'est pas clair qu'il s'agit de la paques occidentale ou orientale calculee sur le calendrier julien orthodoxe. il faudrait ajouter un champ avec un nombre fixe de jours. bien qu'en france seule la paques occidentale est utilisee, ce n'est pas forcement vrai pour les services liees aux confessions orthodoxes ou juives. pour les musulmans il faudrait aussi les dates des fetes de l'haïde (pas sur de l'orthographe) sachant qu'il est probable qu'il y ait leur i troduction a mayotte ou la reunion. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] YoHours version 2 disponible
Merci :) Pour l'internationalisation j'y pense, une autre personne m'a fait la remarque. La barre du haut toujours visible c'est à tester, mais pourquoi pas. Cordialement. Le 20/08/2015 08:56, Renaud a écrit : C'est vraiment super !! Perso. j'aimerais bien : * Du français * Que la barre du haut reste toujours visible ou que l'ensemble tienne sur une seule page ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-es] CheckAutopista2
Creo que ya lo he arreglado. He comprobado con los ejemplos que has mandado y ahora ya muestra los datos correctos. Te agracería Jesus que comprobaras si ya está bien. k1wi 2015-08-20 16:55 GMT+02:00 k1wi . k1wi...@gmail.com: Muchas gracias Jesús por las molestias que te has tomado con las fotos, ejemplos y todo. En seguida me pongo a arreglarlo para que muestre la destination de la way correcta. Me apunto también lo de destination:symbols y destination:ref. ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-it] josm e server api
Qui funziona tutto, sia da JOSM (uso la versione .jnpl che si aggiorna da sola, adesso è la 8491) che da Vespucci sullo smartphone. Ciao /niubii/ Il giorno 20 agosto 2015 17:17, emmexx emm...@tiscalinet.it ha scritto: Il 08/20/2015 04:04 PM, Leonardo Frassetto scrisse: Domanda stupida, josm è aggiornato all'ultima stabile? Magari una re installazione sistema tutto. Stesso problema. Versione 8491 (appena riscaricata). ciao maxx ___ 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] The Proposed Great Colour Shift
For me, the new style is a pointless exercise since I NEED to retain a UK view of the data, and I am sure other countries would also prefer to retain their own road colour preferences so trying to provide an international style has a limited 'market'? If anything it simply drives us to provided more local styled services? Isn't it possible to have separate UK rendering on the same map, like on the Mapquest layer? If such a framework is created it could even open up other renderings for different countries. Thing is that UK won't ever be happy with another colour scheme and the rest of the world won't ever be happy with a UK scheme. Ben ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-fr] Test carte Police/Justice...
Des morceaux d'OSM dedans... essentiellement les contours de communes utilisés pour recréer les limites des TGI et des zones Police/Gendarmerie, le reste c'est 4 jeux de données opendata dispo sur data.gouv.fr https://www.data.gouv.fr/fr/reuses/carte-des-ressorts-des-tgi/ Les usagers potentiels de cette couche (transparente) sont les services de police, de gendarmerie, ainsi que les douaniers (l'idée m'a été soufflée par un douanier). Je n'ai mis en ligne qu'une petite zone autour de Douai. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-ca] Fwd: Ottawa, Canada import
I got an email back from the guy handling the Licensing. Hi James, thank-you for the email. I’m not sure I understand the compatibility grid. Is there a particular issue you are concerned about? Note: we have plans to adapt the Open Government License Canada but have not been able to do that quite yet; however, there are few differences between the two, so if there’s a specific item you are concerned about it I might be able to shed some light on how we treat it. Thank-you, Robert Giggey --- What would be the specifics of our license (ODbL) incompatible with Ottawa-TOU? On Wed, Aug 19, 2015 at 10:14 AM, James james2...@gmail.com wrote: Email I got after I said I will be unable to use the data due to incompatible licensing: James, I’m going to forward this inquiry on to Robert Giggey. He is in charge of the Open Data program at the City. I must say, I am a little surprised that this interpretation is so restrictive. I personally was not aware of this. I will also follow-up with Robert in this regard. *-Stephen* Maybe, they just needed some education? P.s. thank you Stewart for the comparison tool! On Wed, Aug 19, 2015 at 9:23 AM, Stewart C. Russell scr...@gmail.com wrote: Hi James — What should I tell Stephen, to change the license for just OSM or in whole? For simplicity, they'd need to change the licence for everyone. A special carve-out for OSM alone would be fraught with problems. Ideally, they'd chose a licence that isunencumbered, like CC0 or PDDL. Any attempt to roll your own licence adds compatibility problems, and municipalities do love to keep those little clauses in that allow them to recall data. If you want to show Stephen how compatible and open the city's licence isn't, show him this: http://clipol.org/licences/16?tab=licence_compatibility It shows how Canadian municipalities all shared and tweaked licences, and inadvertently made them incompatible with everything. And they complain about why no-one uses their data. If they do want to change (great!), I know there are some folks on this list just itching for a roadtrip to the NCR to do some municipal education … cheers, Stewart ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca -- 外に遊びに行こう！ -- 外に遊びに行こう！ ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-talk] The Proposed Great Colour Shift
Þann 20.8.2015 18:36, skrifaði Frederik Ramm: Your use case of easily recognizable tertiary road in sparsely populated regions is valid, but perhaps it is niche enough to accept that it need to be served by the main map style. I'm fairly certain that the rural regions of the world are not a niche but where we are sorely lacking in data and where our growth in Africa (for example) will come. Having done data quality checks on settlements of the world thousands of them are still just a name on the map with no road connections and there tertiary roads will be needed to go. I'm not averse to red/yellow taking over personally but the expense is too great for me at the moment. We need to find a way to make tertiary still recognizable. --JBJ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-br] RES: Reunião Periodica - OSM Brasil Peter Krauss
Pelo que entendi, ele insere dados de mapas cedidos pelas prefeituras e concessionárias no OSM? Se for isso, no caso dos dados das prefeituras não vejo problemas, pois é publico. Os mapas municipais são públicos, pois são os cidadãos (nós) que mantemos as prefeituras. Qualquer pessoa pode se dirigir à secretaria de obras das prefeituras e obter o mapa de seu município. Já fiz isso algumas vezes e sempre fui bem recebido. Quanto às concessionárias, vejo um problema pois elas disponibilizaram o mapa para a ECT, com a finalidade de ele (mapa) servir de insumo para o cadastro de CEP. Se o faz é por conta e risco. Talvez essa pessoa deve ser alertada. Se qualquer pessoa for à uma concessionário para obter um mapa eles irão disponibilizar? Dependerá da empresa. Quantos às prefeituras, nas cidades do entorno do DF (RIDE), entre 2013 e 2014, estive contactando várias para obtenção de mapas e verifiquei que a situação é precárias na maioria delas. Muitas não tem mapas ou terceirizam sua elaboração para empresas de outras cidades. Crio que isso se estenda pela maioria das cidades pequenas do país. Nesse sentido, percebi que o OSM tem um grande potencial de se tornar uma ferramenta muito poderosa para preencher essa lacuna. Isso porque o seu processo produtivo é muito simples, não requer conhecimentos avançados em informática e nem mesmo na área de cartografia. Isso possibilitaria à essas cidades elaborarem seus próprios mapas a um custo (ou sem ele) baixíssimo. Para tal, precisa ser elaborado (e isso pode envolver o grupo dessa lista) um material sobre a plataforma, para apresentação às prefeituras em potencial. O material poderia ficar no página do osm ou wiki e poderia ser utilizado por qualquer pessoa com interesse e disposição em disseminar o conhecimento. Porque estou falando de prefeituras? Já disso aqui uma vez, e muitos devem saber, que são nas prefeituras que se originam as leis de criação dos logradouros, bairros, loteamentos e condomínios. Depois são aprovadas pelas câmaras municipais. Assim, muitos podem querer fazer mapas, mas a fonte das informações sempre serão das prefeituras. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Solicitação LAI (Lei de Acesso à Informação) ao IPP sobre o Geolog
Arlindo, Creio que sera necessário explicar para o IPP que é importante eles mudarem a politica de divulgação dos dados. Creio que eles estãoa bertos. Se eles limitem para o uso commercial e exigem um atribuição no mapa, não será possivel importar no OSM, mas não creio que seja o intuito deles. Eles só não refletiram espcificamente sobre o OSM ainda. Eu encontrei rapidamente o Luiz Roberto Arueira ( larue...@pcrj.rj.gov.br) e tel: +55 21 29766551 da Silva e falei em novembro com Marco Medeiros (marcomedeiros@gmail.com) e precisamos motiva-los a mudar a politica. Abs. Thierry Jean From: openstreet...@arlindopereira.com Date: Thu, 20 Aug 2015 14:07:49 -0300 To: arma...@pcrj.rj.gov.br CC: ascom.ipp...@gmail.com Subject: Re: [Talk-br] Solicitação LAI (Lei de Acesso à Informação) ao IPP sobre o Geolog Prezados, agradeço pela resposta. Com relação aos dados mencionados do PORTALGEO, tais como: fronteiras de bairro, endereçamento, contornos de construções etc., gostaria de perguntar se as mesmas restrições se aplicam, ou se há uma flexibilização da licença neste caso. Para contexto, meu intuito é, caso seja possível, importar os dados no OpenStreetMap [1], projeto que disponibiliza um mapa de todo o mundo sob licença livre, a partir de dados contribuídos por pessoas, empresas e governos. No Brasil, o OSM conta com dados públicos de diversos órgãos / esferas, desde a nível federal com dados do IBGE até o nível municipal, com contribuições da prefeitura de Vitória. Recentemente, tivemos aprovação para importar dados do portal Geolog da prefeitura de São Paulo. Mais especificamente, os dados importados no OSM são livres para qualquer tipo de utilização, inclusive comercial, e os dados relativos a autoria original viriam apenas como metadados dos objetos e opcionalmente numa página apartada, sem legenda no mapa principal. Agradeço mais uma vez a atenção dispensada. Att.,Arlindo Pereira 1: http://www.openstreetmap.org/about 2015-08-20 13:13 GMT-03:00 Armazem de Dados DIG arma...@pcrj.rj.gov.br: Prezado Sr. Arlindo Pereira, Respondendo sua solicitação para a Assessoria de Comunicação do IPP Atenciosamente, Equipe Armazém de Dados 1) O Cadlog é domínio público? Sim. O Armazém de Dados é um site de disseminação de informações sobre a Prefeitura do Rio. A utilização do seu conteúdo é livre para fins não comerciais e com a devida citação de fonte Prefeitura da cidade do Rio de Janeiro – Instituto Pereira Passos (IPP) – Site Armazém de Dados. Se o Cadlog não for de domínio público: (mesmo assim, acho que pode ser interessante enviar a explicação) 2) Posso utilizá-lo para fins comerciais? Não. 3) Posso fazer trabalhos derivados em cima do mapa (ou seja, modificá-lo e publicar)? Consideramos o CADLOG um aplicativo (Mapa Digital) fechado cujo link pode ser inserido em aplicações ou sites desenvolvidos pelo usuário. Sempre com a citação da fonte. No site do Armazém de Dados, dentro do PORTALGEO, o usuário encontra várias bases que podem ser usadas em projetos. 4) Se eu fizer um trabalho derivado, esse trabalho tem que dar atribuição? Sim. Prefeitura da cidade do Rio de Janeiro – Instituto Pereira Passos (IPP) – Site Armazém de Dados 5) Se tiver atribuição, essa atribuição tem que ficar como legenda do mapa ou pode ficar em uma página apartada? Legendada no mapa. ___ 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] The Proposed Great Colour Shift
On 20/08/15 22:46, Minh Nguyen wrote: - Shields are either reproduced in colors that match the signage, or they're colored to match the road. So a map might end up with white-on-blue Interstate shields, red-on-white U.S. route shields, and black-on-white state route shields. I would consider the proposed style to be closer to what a U.S. visitor would expect than the current UK-influenced style. Actually I'm just looking to ditch the bloody rounded ends on the UK maps ... It's not something I recognise as 'UK style' ... someone invented it ... On OSMAND it makes the road and motorway numbers difficult to read ( and OSMAND has lost the green roads which is something I'm trying to get back there as well! :) ) One thing which I still find a problem is that 'B' roads in the UK are 'yellow', not the unclassified ones so I'd like to loose the orange back to yellow and then correct the problem that having half of the local short cuts difficult to see and other less useful ones highlighted. This is probably simply that the wrong tagging is being used, but some of these smaller roads are essentially main routes so tagging as a 'service road' is correct for the local usage, but not for main stream routing and where the likes of OSMAND simply gets the routing wrong ... as do other routers :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] quand Google court après OSM
Oui enfin, il ne faut pas non plus faire une obsession vis a vis de Google. Je ne suis pas sure qu'il y ait une correlation; ca reste quelque chose qui est dans l'air du temps. De plus ce projet est le projet d'un employe (le fameux 20%), qui a ete repris par Google mediatiquement par la societe en premier lieu. Google reste malgre tout une societe assez concernee par le futur en terme d'ecologie. Cela n'est pas donc pas tres surprenant. Le campus de Google est a ce titre tres interessant avec des plantations de fraisiers a certains endroits. Bref, je digresse mais avoir Google faire de la pub sur ce genre de technologie ne peut que renforcer les societes qui font la meme chose ailleurs avec des technologies similaires. 2015-08-20 14:00 GMT-07:00 osm.sanspourr...@spamgourmet.com: Certains municipalités allemandes proposaient déjà un calcul de l'ensoleillement en se basant sur les données OSM (et je pense de la photo aérienne pour les calculs des orientations des toits). Voici que G... s'y met. Jean-Yvon Source : Futura sciences via [Rezo-actu] http://www.futura-sciences.com/magazines/high-tech/infos/actu/d/technologie-sunroof-google-veut-nous-aider-passer-solaire-59420/ Avec Sunroof, Google veut nous aider à passer au solaire http://www.lefigaro.fr/ Google a en projet un service, qui a pour l'instant le nom de Sunroof, destiné à déterminer si le toit d'un bâtiment conviendrait pour des panneaux solaires. Grâce à Google Earth, on pourrait évaluer le potentiel énergétique d'une toiture en tenant compte de son exposition et estimer les économies réalisables. Le 19/08/2015 à 13:27 - Marc Zaffagni, Futura-Sciences *Déjà fournisseur d’accès Internet par fibre optique, Google pourrait ajouter une nouvelle corde à son arc en proposant de l’installation de panneaux solaires. Le géant américain n’a encore rien annoncé, mais il vient de faire un premier pas dans cette direction avec son projet Sunroof. * Deuxième pays le plus pollueur après la Chine, les États-Unis veulent s’engager dans un ambitieux plan de réduction des émissions http://www.futura-sciences.com/magazines/matiere/infos/dico/d/physique-emission-389/ de CO2 afin de lutter contre le réchauffement climatique http://www.futura-sciences.com/magazines/environnement/infos/dico/d/climatologie-rechauffement-climatique-13827/. Avec la conférence de Paris sur le climat http://www.futura-sciences.com/magazines/environnement/infos/dico/d/climatologie-climat-13771/ (COP 21 http://www.cop21.gouv.fr/fr) en ligne de mire, le président Barack Obama vient d’en faire son ultime combat avant le terme de son mandat qui s’achèvera l’année prochaine. *« Il n'y a pas de défi qui pose une plus grande menace pour notre avenir et pour les générations futures que le changement climatique http://www.futura-sciences.com/magazines/environnement/infos/actu/d/climatologie-changement-climatique-role-doivent-jouer-scientifiques-58567/ »*, a-t-il déclaré en annonçant un programme qui vise à réduire de 32 % les émissions des centrales thermiques nord-américaines d’ici 2030. Les énergies renouvelables http://www.futura-sciences.com/magazines/environnement/infos/dico/d/energie-renouvelable-energie-renouvelable-6634/ sont au cœur de ce plan, en particulier le solaire et l’éolien. Si l’action est évidemment louable, elle représente aussi un attrait économique considérable. Le marché de l’énergie solaire est en plein essor et de nouveaux acteurs s’y intéressent de près. Ainsi, le constructeur de voitures électriques http://www.futura-sciences.com/magazines/environnement/infos/dico/d/energie-renouvelable-voiture-electrique-13758/ Tesla http://www.futura-sciences.com/magazines/matiere/infos/dico/d/physique-tesla-367/ a-t-il récemment dévoilé sa Tesla Powerwall http://www.futura-sciences.com/magazines/environnement/infos/actu/d/energie-renouvelables-tesla-lance-batterie-domestique-pour-transformer-energie-mondiale-58271/, une batterie domestique qui peut stocker l’électricité fournie par des panneaux solaires ou le réseau électrique http://www.futura-sciences.com/magazines/maison/infos/dico/d/maison-reseau-electrique-10888/. Comme d’autres géants de la high-tech, Google http://www.futura-sciences.com/magazines/high-tech/infos/dico/d/internet-google-3987/ est aussi très sensible aux questions environnementales et aux énergies renouvelables http://www.google.com/green/energy/#power. Et la firme californienne vient de lancer un nouveau projet nommé Sunroof http://googlegreenblog.blogspot.fr/2015/08/project-sunroof-mapping-planets-solar.html qui préfigure peut-être de grandes ambitions… [image: Voici à quoi ressemble le projet Sunroof. Les personnes habitant dans l’une des trois régions pilotes aux États-Unis n’ont qu’à entrer leur adresse afin d’obtenir une vue aérienne de leur maison accompagnée d’une évaluation du potentiel d’ensoleillement de leur toiture et des économies réalisables. Sunroof prend en compte
[Talk-de] Wochennotiz Nr. 265 11.8.–17.8.2015
Hallo, die Wochennotiz Nr. 265 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/blog/2015/08/wochennotiz-nr-265/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] The Proposed Great Colour Shift
Paul Johnson baloo at ursamundi.org writes: Along these lines, the standard style as it isn't too far off from what Americans expect out of a motorist-oriented roadmap (though mapgeeks might see it as a bit German by comparison to our maps). Surface streets tend to be all the same color (usually purple or red) with the thickness of the lines tending to be rather thin, increasing in thickness up to primary or sometimes trunk, with motorways tending to be purple with red borders. Toll roads are always green, there's never ways that are green that are not toll. This style of rendering is almost certainly heavily influenced by Rand McNally, given it's ubiquity for casual use maps, which traditionally has favored as described above in a somewhat simplified, stylized form (such as rather than each ramp mapped out in detail, an entire, possibly almost absurdly complex junction, is simplified to a single white square representing a motorway junction). Rand McNally was, for quite a long time, the official cartography provider for the American Automobile Association, which probably helped propel this style as an expectation. Thomas Guide (still usually preferred by professional local drivers even when equipped with a GPS in the US, as a single metro gets published as a lay-flat atlas hundreds or thousands of pages long with detailed annotation, sometimes down to building suite level, at a scale roughly equal to z20 and handy for that last thousand feet navigation) tends to use the same form, but rather than simplifying junctions, often goes the map porn route by mapping out everything to scale without simplification. A few additional observations from having used a variety of print atlases by Rand McNally, DeLorme, and municipal suppliers: - Controlled-access highways (that is, motorways with dual carriageways) are commonly colored red, amber, purple, or blue. The specific color doesn't matter so much, just as long as it isn't green (which is reserved for toll roads, as Paul points out). Motorways are drawn as 2-3 parallel strokes, imitating the dual carriageways. - Limited-access roads (think trunk or primary) are given a single thick stroke, colored black, except for U.S. routes, which are usually red. All other roads are given a single, thin stroke. In the West, prominent unpaved roads might be dashed. There usually aren't any other classifications. - Streets in general are very thin because each street label is placed above the street, not on it. However, I have a few municipal maps that do place the label inside much wider roads, giving the map a more casual feel, less like a schematic. - Full motorway junctions are simplified into white squares or diamonds, while partial junctions are half that: a thin rectangle. At higher zoom levels, a complex junction such as a cloverleaf is drawn in full, but the space inside it is filled in the same color as the motorway. - Shields are either reproduced in colors that match the signage, or they're colored to match the road. So a map might end up with white-on-blue Interstate shields, red-on-white U.S. route shields, and black-on-white state route shields. I would consider the proposed style to be closer to what a U.S. visitor would expect than the current UK-influenced style. -- m...@nguyen.cincinnati.oh.us ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The Proposed Great Colour Shift
On Thursday 20 August 2015, Jc3b3hannes Birgir Jensson wrote: According to the github discussion there is an overwhelming consensus [2] on moving from current rainbow colour scheme for roads to a red-yellow only scheme. Note this comment is mostly based on the early discussion of the matter, in particular in https://github.com/gravitystorm/openstreetmap-carto/issues/102 and in the early diary entries by Mateusz but also in countless comments made over the time elsewhere concerning the road color scheme. This of course does not necessarily mean that all those supporting a change in general are fine with the scheme that is now developed by Mateusz. In general among those in favour of keeping the current scheme there have been only very few specific suggestions how to address the problems this leads to in the style, in particular the fact that the road network as a whole is not recognizable as such and the color conflicts with other colors in the style. If you think a different styling than what is currently proposed would be better it would be best to show it. Suggesting to use a paler yellow for tertiary or the color scheme of a different style is one thing, actually demonstrating how this looks and addressing issues this creates is another. I know setting up the system for doing and viewing style changes is not trivial but if - as you say - there are so many people that would be badly affected by it there should be someone to demonstrate a viable alternative. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The Proposed Great Colour Shift
I'm taking bets on whether this thread will have more replies than the
abandoned railroads (100+ and still going strong!) and win the prize
for the Biggest Waste of Time in OSM for 2015.
YES WE CAN('T)
Paweł
On Thu, Aug 20, 2015, at 03:16, Jóhannes Birgir Jensson wrote:
For those that did not check on Mateusz Konieczny diary entries[1],
postings to this mailing list and github discussions then the Proposed
Great Colour Shift might come as a surprise if it is implemented.
According to the github discussion there is an overwhelming consensus
[2] on moving from current rainbow colour scheme for roads to a
red-yellow only scheme. I am unsure of where this overwhelming consensus
formed because I never saw it on this mailing list nor on talk-dev nor
on announcements, I admit to be an infrequent IRC user but I didn't see
this overwhelming consensus there and so far no one has been able to
tell me where it formed or where I can find it.
The design goal seems straight forward, to discontinue green and blue
for roads and move to red and reddish. For this to happen the decision
was made to shift current primary, secondary and tertiary colours
upwards so primary is now the colour of secondary and secondary the
colour of tertiary. Leaving tertiary white.
Tertiary instead gets to be wider than residential and unclassified
roads, but to be able to spot that you need to have it next to them to
see which is the wider one.
This one simple change of bleaching tertiary however is something I find
to be a great hindrance to mapping efforts, particularly in rural areas
where the roads are isolated and panning over the map, wether in iD or
using default tiles. Currently it is easy to spot tertiary roads snaking
through valleys and over vast desert plains, they are yellow and the non
tertiary roads are white. Tertiary is significant there as it denotes
the roads between the villages and towns that are often unpaved but
still the most important, even the only, road. Lesser white colours
imply the roads not being between larger settlements although they could
lead to hamlets. The guidelines for mapping in Africa state thus.
Removing the colour from tertiary makes all mapping that much harder to
verify and quality check. Currently it is easy to see if a tertiary road
is broken with a white unclassified bridge, not so in the proposed Great
Colour Shift.
Mateusz has been forthcoming with all changes and done sterling work in
displaying different areas and how they will look. But he acknowledges
that this change is not beneficial everywhere on the map and now has a
disclaimer:
Among potential problems are that it is now harder to recognise road
type of given road, especially in situation where there is no
possibility to compare it with other road types.
Such significant change will be confusing for current users of this
style.
UK color coding of roads is well known for many people, for them a new
style - even assuming that it would be intuitive for them - will be less
useful.)
The question really arises if this change is beneficial or not for the
project. Many hours have gone into it and doing CartoCSS on all these
zoom levels is not trivial. But this is a major shift on the front page
of our website, a blow to those who use the default tiles through uMap
or similarly and depend on the UK rainbow road style and makes life
harder for mappers to visually confirm the type of road.
Should this be a new, alternative style instead?
[1] http://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/35586
[2]
https://github.com/gravitystorm/openstreetmap-carto/pull/1736#issuecomment-130592532
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] YoHours version 2 disponible
Merci Adrien pour cette nouvelle version. Est-il possible d'avoir la tirette de descente sur les horaires également en horizontal? Ex: ouverture L-V 8h-12h. On met l'horaire 8h-12h sur le lundi et en tirant sur les autres jours, ca recopie 8h-12h Donat ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] YoHours version 2 disponible
Bonjour, La plupart des factorisations possibles sont déjà mises en place. Quels sont les éléments qui te semblent encore factorisables ? Cordialement. Le 2015-08-20 11:25, Jérôme Seigneuret a écrit : Bonjour, Une factorisation de la chaîne pourrait être intéressante pour ne pas avoir une ligne trop longue. Jérôme ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-es] CheckAutopista2
¡Guau! ¡Qué rapidez! He revisado alguna otra salida de autovía y yo lo veo bien. Un saludo. El 20 de agosto de 2015, 17:27, k1wi . k1wi...@gmail.com escribió: Creo que ya lo he arreglado. He comprobado con los ejemplos que has mandado y ahora ya muestra los datos correctos. Te agracería Jesus que comprobaras si ya está bien. k1wi 2015-08-20 16:55 GMT+02:00 k1wi . k1wi...@gmail.com: Muchas gracias Jesús por las molestias que te has tomado con las fotos, ejemplos y todo. En seguida me pongo a arreglarlo para que muestre la destination de la way correcta. Me apunto también lo de destination:symbols y destination:ref. ___ 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: [OSM-talk] The Proposed Great Colour Shift
As someone affected I wish to dissent therefore you do not have consensus not every one consents. Cheerio John On 20 August 2015 at 12:26, Christoph Hormann chris_horm...@gmx.de wrote: On Thursday 20 August 2015, Andy Townsend wrote: On 20/08/2015 02:16, Jóhannes Birgir Jensson wrote: According to the github discussion there is an overwhelming consensus [2] on moving from current rainbow colour scheme for roads to a red-yellow only scheme. I don't think you'll ever get an overwhelming consensus from such a large committee. :) Yes, i now see that overwhelming consensus is a bad choice of words here - either there is consensus or there is not, it can not be overwhelming. And it only makes sense to speak of consensus with a clearly defined group of people which does not exist here. So i should have better said among those participating in discussions on the matter on several occasions there was a large majority in support for such a change. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] Apresentação e duvida
Outra coisa Arlindo, existe regras de conectividade em respeito a hierarquia das vias? Eu pergunto isso porque na empresa que eu trabalhei, nós não podiamos por exemplo tornar uma via de hierarquia mais alta de repente em hierarquia mais baixa. Por exemplo a Azul era apenas para estradas nacionais, a Verde só poderia nascer da conexão com uma Azul ou Verde e só poderia terminar em outra verde ou em outra azul, nunca terminar em uma vermelha, a vermelha por sua vez poderia surgir e terminar em uma azul, verde ou vermelha, mas jamais poderia terminar em uma laranja, amarela ou branca. Voce poderia falar um pouco sobre isso ou me apontar um documento aonde eu consiga aprender sobre isso uma vez que eu não encontrei exatamente o que estou procurando. Obrigado 2015-08-20 0:37 GMT-03:00 Felipe Castanho felipequadr...@gmail.com: Acredito que seja esse: Caminho: Rua Ribeirão Claro (234368026) Intersecção com a Helio Pellegrino 2015-08-19 19:33 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: 2015-08-19 17:46 GMT-03:00 Felipe Castanho felipequadr...@gmail.com: Muito obrigado Arlindo Então a rota do onibus é modificada apenas porque vai adicionar mais links uma vez que a original passava por DC e agora tem que passar por DP e em seguida por PC correto? Não esta havendo propriamente um desvio na rota, apenas uma correçào. correto? Exatamente. Outra coisa, não estou conseguindo adicionar uma restrição de nao retornar (No U-Turn) Voce pode me explicar? Imagine que de acordo com o seu esquema, exista outra linha paralela a AB nesse caso representando uma avenida com divisor fisico e na realidade voce não pode dirigir de AP e retornar em P sentido PA, como fazer isso? Depende de como está mapeado, se no local do não-retorno há apenas um ponto (isto é, as duas avenidas se tocam junto com a transversal em um único nó) ou se há dois pontos (P1 e P2), um para cada sentido da avenida. Pode passar o link da região? []s Arlindo 2015-08-19 14:14 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: Olá Felipe. É isso mesmo! Explicando: suponha o seguinte cruzamento: [image: Inline image 1] Se existem as vias AB e CD, e você adiciona uma restrição de conversão no ponto P, o que acontece na prática é que as vias são segmentadas (AB vira AP + PB, CD vira CP + PD), com isso na prática são modificadas duas vias e criadas duas vias. Além disso, quaisquer rotas que passem nas ruas AB ou CD também são alteradas (afim de incluir a nova via). PS: A abreviação de OpenStreetMap é OSM ;) []s Arlindo 2015-08-19 13:00 GMT-03:00 Felipe Castanho felipequadr...@gmail.com: Ola a todos, meu nome é Felipe Castanho, a muitos anos atras eu trabalhei com mapeamento, mas fazem 6 anos parei de atuar e estou me interessando novamente pelo assunto, em especifico pelo OMS. Eu peguei uma via como exemplo para tentar entender na pratica como o OMS funciona e fiquei um pouco assustado com as mudanças que ele sugeriu quando apliquei uma restrição de manobra. Vou explicar melhor. Na cidade de SP, região da Vila Olimpia, tem o cruzamento da Av. Helio Pellegrino com a Rua Ribeirão Claro. Na realidade, existe duas restrições de manobras de quem esta na Helio para entrar na Ribeirão, que são: proibido virar a esquerda e proibido retornar. Selecionei o nó, o OMS me apresentou um quadrado com as duas vias e quando cliquei na helio apareceu duas setas verdes, sendo uma delas na ribeirão claro, cliquei nessa seta para aplicar a restrição de manobra e a seta ficou vermelha. Até ai ok. O problema é quando ele me listou 6 alterações, modificando e criando novas estradas primarias tanto para a Helio como a Ribeirão, e ainda por cima modificou uma rota de onibus 477P-10, por fim ele cita a proibição de virar a esquerda. O que me preocupa são essas outras modificações, principalmente a rota do onibus, Talvez essa seja de fato a rota do onibus e eu estou estragando ou talvez a rota seja automatizada e não levava em conta essa restrição. Então eu gostaria de uma ajuda aqui, meu intuito é ajudar e não atrapalhar. Obrigado! Outra questão: como posso adicionar a restrição proibido retornar nesse mesmo cruzamento? OBSERVAÇÃO: eu não apliquei as modificações ok. ___ 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 ___ 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 ___ Talk-br mailing list Talk-br@openstreetmap.org
Re: [OSM-talk] The Proposed Great Colour Shift
On Thu, Aug 20, 2015 at 9:59 AM, Lester Caine les...@lsces.co.uk wrote: On 20/08/15 02:16, Jóhannes Birgir Jensson wrote: The question really arises if this change is beneficial or not for the project. Many hours have gone into it and doing CartoCSS on all these zoom levels is not trivial. But this is a major shift on the front page of our website, a blow to those who use the default tiles through uMap or similarly and depend on the UK rainbow road style and makes life harder for mappers to visually confirm the type of road. Should this be a new, alternative style instead? That a UK version will appear is a simple fact. Ideally I would like anybody looking up OSM in the UK to be directed to that version. That may be a little more difficult to achieve, but removes the WTF provided by a more international solution? The problem of cause is that one has to switch to another server to get areas outside the UK unless we can provided a complete duplicate of the existing service ... retaining the current style base. For me, the new style is a pointless exercise since I NEED to retain a UK view of the data, and I am sure other countries would also prefer to retain their own road colour preferences so trying to provide an international style has a limited 'market'? If anything it simply drives us to provided more local styled services? I don't have a problem with this, the (from a USian perspective) odd style of the rather UK-centric style of the standard and cyclemap styles didn't help with the learning curve. I'm not going to object to the current plans, simply because I don't have to live with it, but I don't think that it IS the right development path for many reasons. Just what is the convention in the US, Russia or China? Along these lines, the standard style as it isn't too far off from what Americans expect out of a motorist-oriented roadmap (though mapgeeks might see it as a bit German by comparison to our maps). Surface streets tend to be all the same color (usually purple or red) with the thickness of the lines tending to be rather thin, increasing in thickness up to primary or sometimes trunk, with motorways tending to be purple with red borders. Toll roads are *always* green, there's *never* ways that are green that are not toll. This style of rendering is almost certainly heavily influenced by Rand McNally, given it's ubiquity for casual use maps, which traditionally has favored as described above in a somewhat simplified, stylized form (such as rather than each ramp mapped out in detail, an entire, possibly almost absurdly complex junction, is simplified to a single white square representing a motorway junction). Rand McNally was, for quite a long time, the official cartography provider for the American Automobile Association, which probably helped propel this style as an expectation. Thomas Guide (still usually preferred by professional local drivers even when equipped with a GPS in the US, as a single metro gets published as a lay-flat atlas hundreds or thousands of pages long with detailed annotation, sometimes down to building suite level, at a scale roughly equal to z20 and handy for that last thousand feet navigation) tends to use the same form, but rather than simplifying junctions, often goes the map porn route by mapping out everything to scale without simplification. Metro Regional Government (the regional government on the Oregon side of the Portland metropolitian area) probably had the most influence on what people expect out of a bicycle map in the US, with the above style for the Thomas Guide being refitted to the same form factor, layout and scale as one would expect from a Rand McNally metro level map (largely for sake of being able to actually stow it conveniently on a bicycle) printed on waterproof, ripstop paper similar to what you'd find on a land surveyor's notebook, though anything that falls outside of the cycleway network is greyed out like an unavailable menu item in a WIMP-style GUI. Difficult intersections and junctions get a red circle around them, dedicated cycleways are purple, surface streets with bike lanes tend to be a thin blue line, bicycle boulevards a thick blue line. Streets in the network that have no bicycle facilities are green if two or all three of these are true: Wide, low motorist speed, low motorist volume (mostly residential side streets that aren't bike boulevards). Yellow if two of the following are true: High motorist speed, high motorist volume, or no escape space (major arterial streets with wide outside lanes and freeways tend to make this). Red qualifies pretty much any situation yellow would if all three yellow conditions are true or two of the yellow conditions but other hazards are present (the kind of thing that only folks like Wolfpack Hustle or someone going for full completion of every Strava KOM in the region are willing to ride, yet somehow get included in the cycleway network). This
Re: [OSM-talk] The Proposed Great Colour Shift
On Thu, Aug 20, 2015 at 10:09:35AM +0200, Marc Gemis wrote: On Thu, Aug 20, 2015 at 3:16 AM, Jóhannes Birgir Jensson j...@betra.is wrote: Should this be a new, alternative style instead? IMHO for every user that likes the new scheme, you will find one that hates it. And vice versa. For the fact that there are a lot of people who havent even heard about this change i doubt the overwhelming consensus aswell. Yes - OSMs color scheme may at first be odd but we now have it for a couple of years and it served us well and i dont see the point in eliminating additional information from the map. Flo -- Florian Lohoff f...@zz.de We need to self-defense - GnuPG/PGP enable your email today! signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The Proposed Great Colour Shift
On 20/08/2015 16:25, Ben Laenen wrote: Thing is that UK won't ever be happy with another colour scheme and the rest of the world won't ever be happy with a UK scheme. ... and then in the UK we can start arguing about and English style vs a Scottish one and then a Yorkshire one vs Surrey :) Cheers, Andy ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-cl] Regiones de Chile
2015-08-20 8:27 GMT-04:00 Cristián Serpell crist...@serpell.cl: A propósito, el otro día entré en en un sitio que tiene un mapa del mundo con fronteras y que permite ver las regiones a diferentes niveles. [...] No logro encontrar de nuevo el sitio! OSM Boundaries muestra las relaciones quizá sea este. https://osm.wno-edv-service.de/boundaries/ Abrazos, Marco Antonio ___ Talk-cl mailing list Talk-cl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cl
Re: [OSM-talk] stop deleting abandoned railroads
On Thu, Aug 20, 2015 at 02:59:34PM +0200, Pieren wrote: I got some examples from the net: [1] https://commons.wikimedia.org/wiki/File:Dunstable,_Dismantled_railway_and_National_Cycle_Network_Route_6_-_geograph.org.uk_-_146322.jpg where is the railway here ? were are the rails ? why should we keep any mention about rails when it's a cycleway now ? map what we see, the path or track and the cuttings/embankments. don't care where the rails are but knowing that it used to be a railway perfectly explains the the characteristic cutting. Mapping the cutting itself is not quite as good. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The Proposed Great Colour Shift
On Thursday 20 August 2015, Andy Townsend wrote: On 20/08/2015 02:16, Jóhannes Birgir Jensson wrote: According to the github discussion there is an overwhelming consensus [2] on moving from current rainbow colour scheme for roads to a red-yellow only scheme. I don't think you'll ever get an overwhelming consensus from such a large committee. :) Yes, i now see that overwhelming consensus is a bad choice of words here - either there is consensus or there is not, it can not be overwhelming. And it only makes sense to speak of consensus with a clearly defined group of people which does not exist here. So i should have better said among those participating in discussions on the matter on several occasions there was a large majority in support for such a change. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The Proposed Great Colour Shift
Lester Caine lester at lsces.co.uk writes: Just what is the convention in the US, Russia or China? Regarding the U.S., Paul and I describe the conventions here in detail: https://lists.openstreetmap.org/pipermail/talk/2015-August/073892.html But the short version is: real highway shields. Their absence is striking to Americans, far more than the highway colors (which aren't as uniform in U.S. print cartography as they are in the U.K.). There are plenty of technical issues to work out, in any case: https://github.com/gravitystorm/openstreetmap-carto/issues/508 -- m...@nguyen.cincinnati.oh.us ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-at] Graz+Innsbruck: »Schiene und Straße wurden getrennt«
On 20.08.2015 23:29, Flaimo wrote: das gegenteilige Problem hast du dann aber wenn du zum Beispiel ein Fußgängerrouting für Blinde implementieren willst, wo es kritisch ist, wie oft einem Gleise auf der Strecke begegnen werden. Das geht mit tracks=2, und das ist sogar besser, weil dann nicht die falsche Abfolge Gleis-Straße-Gleis vorgetäuscht wird. Nachverfolgung von Öffis in Echtzeit würde für eine saubere Darstellung auf einer Karte auch ein getrenntes Mapping voraussetzen. Muss eine saubere Darstellung metergenau sein? Ein derart großer Maßstab hat für so eine Anwendung doch überhaupt keinen Sinn. Prinzipiell sollte es möglich sein aufgrund der Öffi-Routenrelation die beiden Gleise all eine Verbindung interpretieren zu können und bei kurz aufeinanderfolgenden Kreuzungen von unterschiedlichen Ways nur beim ersten Mal einen Hinweis auszugeben. Mit solchen heuristischen Metoden kann man im Einzelfall richtig liegen oder auch falsch. Solang im Datenbestand die Information fehlt, können Anwendungen nur raten. Prinzipiell ist zu sagen das es idR einfach sein wird detaillierte Daten runter zu rechnen und zu vereinfachen, als bereits durch den Mapper eine (subjektive) Vorfilterung vornehmen zu lassen und dann umständlich ungefähr-Annahmen heraus extrapolieren muss. Die Prämisse, nämlich die detaillierten Daten, ist beim Auftrennen nicht gegeben, da die Beziehung zwischen Straße und Gleisen verloren geht. Die Lagerichtigkeit der Gleise wird mit dem Verlust anderer Informationen erkauft. Und wegen dem visuellen Aspekt: Für die Detail-Zoomstufen ibt es area:highway (http://forum.openstreetmap.org/viewtopic.php?id=26317). Da würden dann die Gleise wieder auf der Straße dargestellt werden. Das ist ein Konjunktiv gleich in zweifacher Hinsicht. Erstens hast du dein Proposal im Stich gelassen, es ist verwaist. Zweitens nützt es nichts, wenn man die Straßenfläche mappen kann, solang es keiner tut. Wer die Gleise aufspaltet, müsste im selben Changeset auch die Straßenfläche mappen; das ist in Wien bisher nirgends passiert. Bei höheren Zoomstufen fallen die beiden Gleisstränge dann visuell eh wieder zu einer Linie zusammen. Du meinst niedrigere Zoomstufen (= kleinere Maßstäbe), oder? Sie fallen zu einer Linie zusammen, die dennoch dicker ist als die einzelne Signatur, also womöglich sogar die Straße ganz überdeckt. Es sei denn, der Renderer ist gut im Generalisieren - was bisher auf keinen zutrifft. In Linz sind die Gleise schon seit Jahren getrennt eingezeichnet und bis jetzt hat sich keiner daran gestoßen. Kann aber auch daran liegen, dass außer mir nicht recht viel andere in der Gegend regelmäßig aktiv sind :-) Das vermute ich auch. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Tagging von Bächen als waterway=ditch
On Thursday 20 August 2015, Stephan Wolff wrote: http://www.openstreetmap.org/#map=13/54.3349/9.4072 Dort ist das eigentlich relativ einfach, denn die meisten natürlichen Wasserläufe sind hier kaum begradigt, so dass man sie gut an der Form erkennen kann. Schwieriger ist hier für den Mapper ohne Ortskenntnis eher die Richtung. Die Bezugnahme auf die Vergangenheit vor den menschlichen Eingriffen ist natürlich im Sinne der Überprüfbarkeit etwas heikel. Das macht die Unterscheidung aber noch nicht generell sinnlos. Der historische Ansatz passt nicht zu OSM. In OSM wird generell der aktuelle Zustand erfasst. Das Problem ist hier nicht die Erfassung historischer Zustände, sondern die Bewertung der Gegenwart aufgrund von Erkenntnissen über die Vergangenheit. Das ist an sich ein ganz normaler Vorgang, ein anderes Beispiel hierfür wäre die Erfassung geologischer Phänomene (was in OSM recht unüblich ist aber ohne Zweifel möglich). Hier werden in der Gegenwart beobachtbare Phänomene aufgrund von Wissen über ihre Entstehung eingeordnet. Das ist bei Gewässern nicht so viel anders. Wer die ganze Unterscheidung komplett abschaffen möchte sollte bedenken, dass dies den Nutzen der Daten insbesondere in wasserbaulich stark erschlossenen Gebieten enorm einschränken würde. Welche Anwendungen braucht die Unterscheidung nach der Entstehung des Gewässers? Alle Anwendungen, bei denen in irgendeiner Form eine Analyse der Struktur des Gewässernetzwerkes stattfindet. Der zentrale Punkt ist, dass natürliche Fließgewässer generell den steilsten Weg bergab fließen. Dies in Kombination mit der Kontinuitätsbedingung (also dass Wasser nirgendwo einfach so auftaucht oder verschwindet) ist die wichtigste Rahmenbedingung dafür wie sich das Wasser natürlicherweise auf der Erdoberfläche bewegt. Man kann auf Grundlage dieser Regeln und der elementaren Geometrien der Wasserläufe im Grunde sehr viele zusätzliche Informationen herleiten, ohne dass man sie aufwändig in der Natur messen muss. Für künstliche Wasserläufe gilt beides nicht (Kontinuität im engeren Sinne natürlich schon, jedoch nicht nach außen wenn man Tunnel und Druckstollen mit einbezieht). Wenn man künstlichen Wasserfluss mit in eine solche Analyse einbeziehen möchte, bräuchte man hierfür eine Menge Daten über die Struktur der künstlichen Gewässer und die Eigenschaften und den Betrieb wasserbaulicher Einrichtungen die zum größten Teil OSM nicht zugänglich sind. Der einzig praktikable Weg ist also die künstlichen Strukturen aus solchen Analysen weitestgehend herauszunehmen und das kann man natürlich nur dann, wenn man sie in den Daten von den natürlichen unterscheiden kann. Natürlich erzeugt eine solche Vorgehensweise zusätzliche Fehler, denn man vernachlässigt ja die künstlichen Strukturen, jedoch sind ungenaue Informationen meist immer noch besser als gar keine Informationen. -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Graz+Innsbruck: »Schiene und Straße wurden getrennt«
Hallo, Am 21.08.2015 um 00:19 schrieb Friedrich Volkmann: On 20.08.2015 23:29, Flaimo wrote: In Linz sind die Gleise schon seit Jahren getrennt eingezeichnet und bis jetzt hat sich keiner daran gestoßen. Kann aber auch daran liegen, dass außer mir nicht recht viel andere in der Gegend regelmäßig aktiv sind :-) Das vermute ich auch. Nicht ganz. So aktiv wie in Wien oder Graz ist die Community in Linz wohl nicht (mehr), inklusive mir. Aber auch ich habe, als ich noch aktiver war, mit (Richtungs- und von Straßen) getrennten Straßenbahngleisen die besseren Erfahrungen gemacht, und kann Flaimo nur zustimmen. Andererseits sollte ein in einer Region etablierter Konsens natürlich auch nicht einfach von einzelnen ohne Diskussion über den Haufen geworfen werden ... -- Holger Schoener nume...@ancalime.de signature.asc Description: OpenPGP digital signature ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
