Re: [OSM-talk] humanitarian rendering in a degraded state

Humanitarian tiles are back online after a DB reimport. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] humanitarian rendering in a degraded state

Hello, Following 3 simultaneous problems: - problem with osmosis in the recovery of the diffs to update the database. - disk space saturation due to a regression in the management expiration files - network problem between the rendering server and the 2nd backup database. humanitarian rendering

[OSM-talk] OSM Rendering Server

Hi, Since September 2016 I've been sponsoring a rendering server for OSM tiles called `vial` out of personal finance. It is set up on Hetzner. This month Belarus tax regulations changed, and Hetzner starts charging 20% more from Belarus residents. If somebody is willing to take the flag of

[OSM-talk] Maps rendering forum

Hi, I think we need a place to discuss maps rendering using OSM data, so I created special subforum to talk about it: https://forum.openstreetmap.org/viewforum.php?id=100 -- "My method is uncertain/ It's a mess but it's working" [F. Apple] ___

Re: [OSM-talk] Planned rendering changes of protected areas

2017-12-03 4:05 GMT+01:00 Daniel Koć : > > 1. As I currently understand it, nature reserve is _always_ a type of > protected area, to begin with. > > We were talking on osm-carto ticket with some people about private > reserves and even when someone told me "it's not about

Re: [OSM-talk] Planned rendering changes of protected areas

W dniu 11.12.2017 o 14:43, Greg Troxel pisze: The property that is denoted by leisure=nature_reserve is mostly separate from the protected area information. It means that humans are able to hike in a land wich is in a natural state. In the meantime I've made a reality check with Poland

Re: [OSM-talk] Planned rendering changes of protected areas

Daniel Koć writes: > W dniu 07.12.2017 o 17:04, Greg Troxel pisze: >> I also object to deprecating leisure=nature_reserve. The protected_area >> scheme is too complicated for most people to deal with fully and >> leisure=nature_reserve has proved itself to be useful. > >

Re: [OSM-talk] Planned rendering changes of protected areas

W dniu 07.12.2017 o 17:04, Greg Troxel pisze: I also object to deprecating leisure=nature_reserve. The protected_area scheme is too complicated for most people to deal with fully and leisure=nature_reserve has proved itself to be useful. This way or another it seems to me that leisure= key is

Re: [OSM-talk] Planned rendering changes of protected areas

Christoph Hormann writes: > On Thursday 30 November 2017, Daniel Koc4‡ wrote: >> >> I'm thinking about changes in rendering of protected areas on >> osm-carto and I wanted to give community a hint, because it's a >> popular kind of objects. > >> 1. Currently

Re: [OSM-talk] Tagging/rendering relations

W dniu 03.12.2017 o 19:31, Yves pisze: Because the discussion can be heated by the fear of seeing something 'disappear' from the map overnight. Well, the fear might be there, but the discussion was already here, it was not too heated, and that was just my conclusions after the discussion. I

Re: [OSM-talk] Tagging/rendering relations

Le 3 décembre 2017 19:07:24 GMT+01:00, "Daniel Koć" a écrit : W dniu 03.12.2017 o 18:43, Yves pisze: I do agree with Christoph here, tag depreciation should be discussed outside of the scope of osm-carto. It would be interesting for me to hear the exact reasons why do

[OSM-talk] Tagging/rendering relations

W dniu 03.12.2017 o 18:43, Yves pisze: I do agree with Christoph here, tag depreciation should be discussed outside of the scope of osm-carto. It would be interesting for me to hear the exact reasons why do you think that? I would also like to know how do you think should we talk about the

Re: [OSM-talk] Planned rendering changes of protected areas

I do agree with Christoph here, tag depreciation should be discussed outside of the scope of osm-carto. Daniel, this all thread looks like you want to promote a tagging scheme for the primary reason you can't make it look nice on the slippy map. That's really not helping tagging discussions!

Re: [OSM-talk] Planned rendering changes of protected areas

W dniu 03.12.2017 o 11:06, Christoph Hormann pisze: As said before: *do not mix rendering and tagging discussions*. I don't fully understand what you're suggesting (it's a long, complex sentence), but I feel you're  accusing me of something bad. Please note that the first point about

Re: [OSM-talk] Planned rendering changes of protected areas

On Sunday 03 December 2017, Daniel Koc4� wrote: > > TL;DR summary: I think that for now we should render all the existing > tags with osm-carto, but make some of them appear earlier to > encourage smooth migration to a more precise scheme. You are clearly out of line here - the suggestion that

Re: [OSM-talk] Planned rendering changes of protected areas

Thanks for the comments! They help me to get the bigger picture, which is not visible from just the tag names and definitions. TL;DR summary: I think that for now we should render all the existing tags with osm-carto, but make some of them appear earlier to encourage smooth migration to a

Re: [OSM-talk] Planned rendering changes of protected areas

On 30/11/17 13:46, Daniel Koć wrote: Hi, I'm thinking about changes in rendering of protected areas on osm-carto and I wanted to give community a hint, because it's a popular kind of objects. There is a fresh discussion about it from this comment on:

Re: [OSM-talk] Planned rendering changes of protected areas

On Thu, Nov 30, 2017 at 9:38 PM, Eugene Alvin Villar wrote: > On Fri, Dec 1, 2017 at 8:58 AM, Paul Johnson wrote: > >> On Thu, Nov 30, 2017 at 6:05 PM, ajt1...@gmail.com >> wrote: >> >>> On 30/11/2017 13:46, Daniel Koć wrote: >>>

Re: [OSM-talk] Planned rendering changes of protected areas

On Fri, Dec 1, 2017 at 8:58 AM, Paul Johnson wrote: > On Thu, Nov 30, 2017 at 6:05 PM, ajt1...@gmail.com > wrote: > >> On 30/11/2017 13:46, Daniel Koć wrote: >> >>> 1. Currently leisure=nature_reserve (old scheme) and boundary=* (new >>> scheme) are

Re: [OSM-talk] Planned rendering changes of protected areas

On Thu, Nov 30, 2017 at 6:05 PM, ajt1...@gmail.com wrote: > On 30/11/2017 13:46, Daniel Koć wrote: > >> 1. Currently leisure=nature_reserve (old scheme) and boundary=* (new >> scheme) are frequently tagged in parallel, and it looks like the old scheme >> is used as a hack just

Re: [OSM-talk] Planned rendering changes of protected areas

sent from a phone On 30. Nov 2017, at 23:09, Daniel Koć wrote: >> There are 62k uses of boundary=protected_area and 77k of >> leisure=nature_reserve and 31k of the combination - which does not >> really support your idea that the latter is used just as a hack. > > How would

Re: [OSM-talk] Planned rendering changes of protected areas

On 30/11/2017 13:46, Daniel Koć wrote: 1. Currently leisure=nature_reserve (old scheme) and boundary=* (new scheme) are frequently tagged in parallel, and it looks like the old scheme is used as a hack just to make it visible on default map. Just to chuck one example in - I've tagged lots of

Re: [OSM-talk] Planned rendering changes of protected areas

W dniu 30.11.2017 o 17:38, Christoph Hormann pisze: There are 62k uses of boundary=protected_area and 77k of leisure=nature_reserve and 31k of the combination - which does not really support your idea that the latter is used just as a hack. How would you detect such a hack then? In my

Re: [OSM-talk] Planned rendering changes of protected areas

On Thu, Nov 30, 2017 at 7:46 AM, Daniel Koć wrote: > Hi, > > I'm thinking about changes in rendering of protected areas on osm-carto > and I wanted to give community a hint, because it's a popular kind of > objects. There is a fresh discussion about it from this comment on: > >

Re: [OSM-talk] Planned rendering changes of protected areas

On Thursday 30 November 2017, Daniel Koc4� wrote: > > I'm thinking about changes in rendering of protected areas on > osm-carto and I wanted to give community a hint, because it's a > popular kind of objects. I have no definitive opinion on the tagging question but i consider your approach here

[OSM-talk] Planned rendering changes of protected areas

Hi, I'm thinking about changes in rendering of protected areas on osm-carto and I wanted to give community a hint, because it's a popular kind of objects. There is a fresh discussion about it from this comment on:

Re: [OSM-talk] Ravines rendering in Mapnik

sent from a phone > On 21. May 2017, at 10:52, Javier Sánchez Portero > wrote: > > Hello. > > My name is Javier, from Spain. From yesterday, Mapnik is rendering the > waterway=stream, intermittent=yes way with ugly black lines instead of the > ussal dotted light

[OSM-talk] Ravines rendering in Mapnik

Hello. My name is Javier, from Spain. From yesterday, Mapnik is rendering the waterway=stream, intermittent=yes way with ugly black lines instead of the ussal dotted light blue. https://b.tile.openstreetmap.org/16/32646/25173.png Best regards. ___

Re: [OSM-talk-be] Rendering of stream "Leie" broken

-- > Van: Glenn Plas [mailto:gl...@byte-consult.be] > Verzonden: donderdag 28 juli 2016 23:03 > Aan: OpenStreetMap Belgium > Onderwerp: Re: [OSM-talk-be] Rendering of stream "Leie" broken > > > Wat ik trouwens wel een grappige changeset comment vind is de probl

Re: [OSM-talk-be] Rendering of stream "Leie" broken

bericht- Van: Glenn Plas [mailto:gl...@byte-consult.be] Verzonden: donderdag 28 juli 2016 23:03 Aan: OpenStreetMap Belgium Onderwerp: Re: [OSM-talk-be] Rendering of stream "Leie" broken Wat ik trouwens wel een grappige changeset comment vind is de problematische way : https://www.openstr

Re: [OSM-talk-be] Rendering of stream "Leie" broken

Just some notes on waterway=river vs natural=water+water=river. For me, a riverbank is either a line (a wall) separating the land from the river, or a sloped land area with water-loving plants that can be inundated when the water level rises. When you describe the water of the river, you

Re: [OSM-talk-be] Rendering of stream "Leie" broken

Now back on topic: we have the Leie's banks back on the render. On donderdag 28 juli 2016 17:54 Jakka wrote: > https://www.openstreetmap.org/note/646584#map=17/50.82877/3.25798=N > > Please feedback what and where was the cause There were two places where there were problems with relation

Re: [OSM-talk-be] Rendering of stream "Leie" broken

On 28-07-16 22:38, Karel Adams wrote: > Hehe, Glenn, zo'n openhartig antwoord apprecieer ik wel. Ik heb geprobeerd het proper te houden met respect voor de mening van ieder individu, vandaar dat ik me oprecht afvroeg wat 'veel' voor je betekende. :) > Wat ik eigenlijk bedoelde te zeggen: er moet

Re: [OSM-talk-be] Rendering of stream "Leie" broken

On donderdag 28 juli 2016 20:38 Karel Adams wrote: > Wat ik eigenlijk bedoelde te zeggen: er moet toch ergens een "howto" of > een "preferred practice" zijn voor het mappen van een courant en > essentieel landschapselement als een rivier? > > Enne, jawel, het ging er me over dat er op tijd van

Re: [OSM-talk-be] Rendering of stream "Leie" broken

Hehe, Glenn, zo'n openhartig antwoord apprecieer ik wel. Wat ik eigenlijk bedoelde te zeggen: er moet toch ergens een "howto" of een "preferred practice" zijn voor het mappen van een courant en essentieel landschapselement als een rivier? Enne, jawel, het ging er me over dat er op tijd van

Re: [OSM-talk-be] Rendering of stream "Leie" broken

On donderdag 28 juli 2016 22:21 Glenn Plas wrote: > On 28-07-16 22:03, Ruben Maes wrote: > > On donderdag 28 juli 2016 21:56 Glenn Plas wrote: > >> No , not for canals, when I researched this became pretty clear this > >> was only meant for rivers. But the Leie is a river so it's ok here. > > >

Re: [OSM-talk-be] Rendering of stream "Leie" broken

On 28-07-16 22:03, Ruben Maes wrote: > On donderdag 28 juli 2016 21:56 Glenn Plas wrote: >> No , not for canals, when I researched this became pretty clear this >> was only meant for rivers. But the Leie is a river so it's ok here. > > Well that's weird, because there's a canal connected to the

Re: [OSM-talk-be] Rendering of stream "Leie" broken

Wat ik in dit hele verhaal compleet niet snap: Waarom is e nu klapsplots zoveel te doen over het mappen van 1 rivier (en dan nog *) Waarom zou die Leie anders gemapt worden dan de Rijn of de Seine of de Nete, Klein of Groot? Verder bemoei ik me niet met de discussie, ze gaat duidelijk

Re: [OSM-talk-be] Rendering of stream "Leie" broken

On donderdag 28 juli 2016 21:51 Marc Gemis wrote: > Some background: the natural=water, water = x was proposed by Zverik. > His idea was to make it easy for mappers using aerial imagery to map > anything "water"-like with natural=water, eventually someone would add > the water=x detail. x, can be

Re: [OSM-talk-be] Rendering of stream "Leie" broken

On donderdag 28 juli 2016 21:56 Glenn Plas wrote: > No , not for canals, when I researched this became pretty clear this > was only meant for rivers. But the Leie is a river so it's ok here. Well that's weird, because there's a canal connected to the river and it also needs cleaning, and we

Re: [OSM-talk-be] Rendering of stream "Leie" broken

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28-07-16 21:42, Ruben Maes wrote: > Hi Glenn > > We can do away with the relation and make sure waterway=riverbank > is placed everywhere. But this has seemed always strange to me: for > canals as well? A canal is not a river, and the wiki on >

Re: [OSM-talk-be] Rendering of stream "Leie" broken

Some background: the natural=water, water = x was proposed by Zverik. His idea was to make it easy for mappers using aerial imagery to map anything "water"-like with natural=water, eventually someone would add the water=x detail. x, can be pond, stream, river, canal, oxbow, etc. etc. [1] carto-css

Re: [OSM-talk-be] Rendering of stream "Leie" broken

Hi Glenn We can do away with the relation and make sure waterway=riverbank is placed everywhere. But this has seemed always strange to me: for canals as well? A canal is not a river, and the wiki on waterway=riverbank says: "This describes the tagging scheme for large rivers", linking to the

Re: [OSM-talk-be] Rendering of stream "Leie" broken

Hey Ruben, >> I do not see the merit of natural=water scheme at all on a river or a >> canal. It's a waterway. imho, there is nothing to migrate to. >> Unless I seriously missed something, the way to do it is the way (not >> the area) is the logical waterway. > > Both have disadvantages. They

Re: [OSM-talk-be] Rendering of stream "Leie" broken

On donderdag 28 juli 2016 20:42 Glenn Plas wrote: > On 28-07-16 20:10, Ruben Maes wrote: > > On donderdag 28 juli 2016 19:34 Glenn Plas wrote: > >> Ik vraag me ook sterk af wat de bedoeling is van de 2de relatie > >> die ook Leie heet waarin enkel de riverbanks steken. > > > > I believe someone

Re: [OSM-talk-be] Rendering of stream "Leie" broken

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28-07-16 20:10, Ruben Maes wrote: > On donderdag 28 juli 2016 19:34 Glenn Plas wrote: >> Ik vraag me ook sterk af wat de bedoeling is van de 2de relatie >> die ook Leie heet waarin enkel de riverbanks steken. > > I believe someone tried to migrate

Re: [OSM-talk-be] Rendering of stream "Leie" broken

On donderdag 28 juli 2016 19:34 Glenn Plas wrote: > Ik vraag me ook sterk af wat de bedoeling is van de 2de relatie die > ook Leie heet waarin enkel de riverbanks steken. I believe someone tried to migrate to the natural=water scheme but didn't remove the waterway=riverbank. > Als ik straks ga

Re: [OSM-talk-be] Rendering of stream "Leie" broken

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ik vraag me ook sterk af wat de bedoeling is van de 2de relatie die ook Leie heet waarin enkel de riverbanks steken. Als ik straks ga meten hoelang de Leie is adhv. deze data gaat dit niet juist zijn. https://www.openstreetmap.org/relation/1201127

Re: [OSM-talk-be] Rendering of stream "Leie" broken

Seems someone screwed up the Leie multipolygon relation pretty bad. I can deal with it after dinner. On donderdag 28 juli 2016 18:56 Glenn Plas wrote: > Area=no should not be needed on a riverbank. It's implied by creating > a closed way. The problem is elsewhere. > > Glenn > > > On

Re: [OSM-talk-be] rendering

Ook off-line OSM kaarten en gpx-visualisatie daarop zijn mogelijk met een app, zoals Geopaparazzi. Belgie neemt ongeveer 350MB op je SD. Met je GPS zie je waar je bent op de kaart en of je nog steeds op de omloop bent. Door zoomen heb je veel meer details dan de papieren map. Er zijn knoppen

Re: [OSM-talk-be] rendering

On 2016-07-18 21:59, joost schouppe wrote: > Nu het toch suggesties aan het regenen is: QGIS. Met de Openlayers > plugin kan je verschillende stijlen van OSM op de achtergrond > weergeven. De gpx kan je gewoon in het programma slepen. Er zit ook > iets in om prints te maken, maar in de praktijk

Re: [OSM-talk-be] rendering

met maperative zou je dat redelijk eenvoudig zelf moeten kunnen maken je moet dan wel software lokaal installeren 2016-07-18 20:19 GMT+02:00 wannes : > je GPX opladen in www.afstandmeten.nl en dan afdrukken. > > Je kan ook eens contact opnemen met >

Re: [OSM-talk-be] rendering

On 2016-07-18 20:10, Bart Vanherck wrote: Beste mappers, Weet iemand in de groep hier of er ergens een service of een programma bestaat waarmee ik een gpx trace op een openstreetmap layer kan plaatsen. Het doel is om

[OSM-talk-be] rendering

Beste mappers, Weet iemand in de groep hier of er ergens een service of een programma bestaat waarmee ik een gpx trace op een openstreetmap layer kan plaatsen. Het doel is om een redelijk gedetailleerde kaart te hebben om af te printen. Ik ga namelijk de dodentocht doen, en mijn volgers zouden

Re: [OSM-talk-be] rendering

Best even kijken op http://wiki.openstreetmap.org/wiki/OSM_on_Paper , ik zelf vind https://www.mapz.com/ wel goed, al is het niet gratis voor alle doeleinden. Als je tevreden bent met een screenshot, dan is umap ook heel goed. Mvg, Sander Op 18-jul.-2016 20:11 schreef "Bart Vanherck"

Re: [OSM-talk] OSM.org rendering and features [was Re: The Proposed Great Colour Shift]

On Thu, Aug 20, 2015 at 4:51 PM, Daniel Koć daniel@koć.pl wrote: 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

[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

Re: [OSM-talk] Standard rendering totally fuzzy for countries boundaries

Thanks for the link to the good github repo. I did not expect to be the first one to point this out. Same issues and suggestions have been made at least on June 10, 2014: https://github.com/gravitystorm/openstreetmap-carto/issues/622 Do the people in charge of the rendering plan to solve this? The

Re: [OSM-talk] Standard rendering totally fuzzy for countries boundaries

On 26/02/2015, Severin Menard severin.men...@gmail.com wrote: Hi, I would like to know where is the good door to knock on to report an issue with the OSM standard rendering. For a few months, it became totally fuzzy regarding the countries boundaries, almost preventing to distinguish the

Re: [OSM-talk] Standard rendering totally fuzzy for countries boundaries

On 26 February 2015 at 12:39, Severin Menard severin.men...@gmail.com wrote: I would like to know where is the good door to knock on to report an issue with the OSM standard rendering. For a few months, it became totally fuzzy regarding the countries boundaries, almost preventing to distinguish

[OSM-talk] Standard rendering totally fuzzy for countries boundaries

Hi, I would like to know where is the good door to knock on to report an issue with the OSM standard rendering. For a few months, it became totally fuzzy regarding the countries boundaries, almost preventing to distinguish the countries from each other. Eg in Westerm Africa from zoom 4, then zoom

Re: [OSM-talk] Standard rendering totally fuzzy for countries boundaries

On 26 February 2015 at 13:56, Severin Menard severin.men...@gmail.com wrote: Do the people in charge of the rendering plan to solve this? The UI is improving more and more, would be great if the standard map becomes fully understandable. Yes, we're planning to solve this (it is bothering me

Re: [OSM-talk-be] Rendering amenity=parking and access=private

There are open issues: https://github.com/gravitystorm/openstreetmap-carto/issues/1012 https://github.com/gravitystorm/openstreetmap-carto/issues/312 On 12 February 2015 at 11:11, Jakka vdmfrank...@gmail.com wrote: Is it possible that the rendering of a public parking or private are the same.

Re: [OSM-talk-be] Rendering amenity=parking and access=private

I do see a difference, see http://www.openstreetmap.org/#map=19/50.94904/3.12494 The private parking (next to The Bull) is rendered paler than the public parkings. Though mapnik also considers access=customers as private, which is a bit strange. Regards, Sander 2015-02-12 11:20 GMT+01:00 althio

Re: [OSM-talk-be] Rendering amenity=parking and access=private

Someone who do not knows the meaning of that little colour difference ?? Or on a handheld device in the sun ??? Sander Deryckere schreef op 12/02/2015 om 11:24: I do see a difference, see http://www.openstreetmap.org/#map=19/50.94904/3.12494 The private parking (next to The Bull) is rendered

Re: [OSM-talk] Drop rendering of permissive access?

Thank you for all the comments. Based on the comments here and on Github, we have decided to drop the rendering of access=permissive. I'm also happy with all comments that go beyond the access=permissive issue. We will take them into account when making further changes. -- Matthijs On 30 June

Re: [OSM-talk] Drop rendering of permissive access?

Am 16/lug/2014 um 19:48 schrieb martyn i...@dynoyo.plus.com: So having them surveyed and mapped in OSM is a useful addition to PROW data, as information about them is not easy to find. the plan is to remove the access restriction rendering, not the highway itself...

Re: [OSM-talk] Drop rendering of permissive access?

Here in England and Wales, permissive footpaths and permissive bridleways are useful additions to the countryside access network. I recently discovered and mapped some that have been established by the organisation Natural England. They are often used to link existing Public Rights of Way

Re: [OSM-talk] Drop rendering of permissive access?

Theodin writes: For me it was always clear that the standard access appearing on the map was meant for cars. Interesting. See, I always interpreted access as being the legal permission needed to traverse a way. access=permissive means that you might or might not have already been given

Re: [OSM-talk] Drop rendering of permissive access?

Matthijs Melissen writes: We are currently considering dropping the rendering of access=permissive Thank you for bringing this up for discussion in advance of implementing it. This way, bad edits can be averted before they become a fait accompli. -- --my blog is at

Re: [OSM-talk] Drop rendering of permissive access?

For me it was always clear that the standard access appearing on the map was meant for cars. Thats what we are all used to as other maps do the same. That has worked for me most of the time although I mostly use my feet or my bike to get around. I never expected bike/foot-related access on the

Re: [OSM-talk] Drop rendering of permissive access?

2014-07-02 10:01 GMT+02:00 Theodin theo...@posteo.de: For me it was always clear that the standard access appearing on the map was meant for cars. I'd say if a way was meant primarily for cars (primary, secondary, tertiary, residential, unclassified, service) then render access for cars. If

Re: [OSM-talk] Drop rendering of permissive access?

Regardless of aesthetics, as pointed out here https://github.com/gravitystorm/openstreetmap-carto/pull/371 the current access renderings are misleading and entice wrong tagging. So either we do it properly, which would imply importing more data, or we drop the rendering. Simon On 1. Juli 2014

Re: [OSM-talk] Drop rendering of permissive access?

On 01/07/2014 09:46, Simon Poole wrote: Regardless of aesthetics, as pointed out here https://github.com/gravitystorm/openstreetmap-carto/pull/371 the current access renderings are misleading and entice wrong tagging. Playing devil's advocate here, how do we know this? That information

Re: [OSM-talk] Drop rendering of permissive access?

On Tue, Jul 1, 2014 at 5:33 AM, Marc Gemis marc.ge...@gmail.com wrote: Maybe we need two styles on the osm.orgm style Perhaps we don't have to go so far. I would suggest a compromise : render differently open access for the public (access=yes or absence of tag), forbidden access for the public

Re: [OSM-talk] Drop rendering of permissive access?

http://taginfo.openstreetmap.ch/tags/access=destination#combinations ~3700 access=destination that are guaranteed* to be wrong and that is only for a small part of Europe (and yes it is practically impossible to get access=destination plus exceptions right). Simon * foot and similar

Re: [OSM-talk] Drop rendering of permissive access?

2014-07-01 11:53 GMT+02:00 Pieren pier...@gmail.com: Perhaps we don't have to go so far. I would suggest a compromise : render differently open access for the public (access=yes or absence of tag), forbidden access for the public (access=no or access=private) and conditional access, whatever

[Talk-br] Fwd: [OSM-talk] Drop rendering of permissive access?

...@matthijsmelissen.nl Date: Mon, Jun 30, 2014 at 6:23 PM Subject: [OSM-talk] Drop rendering of permissive access? To: OpenStreetMap t...@openstreetmap.org We are currently considering dropping the rendering of access=permissive (currently rendered as green dashes) from openstreetmap-carto, the main map

Re: [Talk-br] Fwd: [OSM-talk] Drop rendering of permissive access?

On Tue, Jul 1, 2014 at 2:09 PM, Arlindo Pereira openstreet...@arlindopereira.com wrote: Discussão interessante no GitHub sobre se o openstreetmap-carto (estilo padrão de renderização no site do OSM) deveria deixar de suportar a tag access=permissive, atualmente renderizado em um pontilhado

Re: [Talk-br] Fwd: [OSM-talk] Drop rendering of permissive access?

do OSM) deveria deixar de suportar a tag access=permissive, atualmente renderizado em um pontilhado verde. []s Arlindo -- Forwarded message -- From: Matthijs Melissen i...@matthijsmelissen.nl Date: Mon, Jun 30, 2014 at 6:23 PM Subject: [OSM-talk] Drop rendering

Re: [Talk-br] Fwd: [OSM-talk] Drop rendering of permissive access?

: Matthijs Melissen i...@matthijsmelissen.nl Date: Mon, Jun 30, 2014 at 6:23 PM Subject: [OSM-talk] Drop rendering of permissive access? To: OpenStreetMap t...@openstreetmap.org We are currently considering dropping the rendering of access=permissive (currently rendered as green dashes) from

Re: [Talk-br] Fwd: [OSM-talk] Drop rendering of permissive access?

...@matthijsmelissen.nl Date: Mon, Jun 30, 2014 at 6:23 PM Subject: [OSM-talk] Drop rendering of permissive access? To: OpenStreetMap t...@openstreetmap.org

Re: [Talk-br] Fwd: [OSM-talk] Drop rendering of permissive access?

Arlindo -- Forwarded message -- From: Matthijs Melissen i...@matthijsmelissen.nl Date: Mon, Jun 30, 2014 at 6:23 PM Subject: [OSM-talk] Drop rendering of permissive access? To: OpenStreetMap t...@openstreetmap.org We are currently considering dropping the rendering of access

Re: [Talk-br] Fwd: [OSM-talk] Drop rendering of permissive access?

-- From: Matthijs Melissen i...@matthijsmelissen.nl Date: Mon, Jun 30, 2014 at 6:23 PM Subject: [OSM-talk] Drop rendering of permissive access? To: OpenStreetMap t...@openstreetmap.org We are currently considering dropping the rendering of access=permissive (currently rendered

[OSM-talk] Drop rendering of permissive access?

We are currently considering dropping the rendering of access=permissive (currently rendered as green dashes) from openstreetmap-carto, the main map on opensteetmap.org. See here for the discussion: https://github.com/gravitystorm/openstreetmap-carto/issues/682 We would welcome any feedback from

Re: [OSM-talk] Drop rendering of permissive access?

On Mon, 30 Jun 2014 22:23:59 +0100 Matthijs Melissen i...@matthijsmelissen.nl wrote: We are currently considering dropping the rendering of access=permissive (currently rendered as green dashes) from openstreetmap-carto, the main map on opensteetmap.org. See here for the discussion:

Re: [OSM-talk] Drop rendering of permissive access?

On 30/06/2014 22:23, Matthijs Melissen wrote: We are currently considering dropping the rendering of access=permissive (currently rendered as green dashes) from openstreetmap-carto, the main map on opensteetmap.org http://opensteetmap.org. What would be useful would be some comments from the

Re: [OSM-talk] Drop rendering of permissive access?

I'll agree with Andy. Don't drop map features for aesthetic reasons. Maybe we need two styles on the osm.orgm style, a nice one for map users and and ugly, but loaded with features mappers-map. regards m On Tue, Jul 1, 2014 at 1:56 AM, SomeoneElse li...@mail.atownsend.org.uk wrote: On

[OSM-talk] Coastline rendering in Quebec

On the talk-ca list there have been a few discussion about problems with flooded areas in southern Quebec. The conclusion seems to be that the problems are due to the rendering of the coastline which only gets updated every once in a while. The two cases are: *

[OSM-talk] Mapnik rendering issue with *_link roads

I finally found out what the issue is with this [1] situation. My issue with it is that IMHO it is not good to see the unclassified road rendered on top of the primary_link road. I made a test here [2] where the left primary is a primary_link and the right primary is a primary proper.

Re: [OSM-talk] Mapnik rendering issue with *_link roads

Logically, you need to know the lower of the two classifications being linked, and it may also be useful to know the higher of the two being linked. So I record that information in links_lower and links_higher tags. Then it can be rendered very neatly. But I got flamed last time I proposed this

Re: [OSM-talk] Mapnik rendering issue with *_link roads

On Fri, May 4, 2012 at 8:09 AM, Maarten Deen md...@xs4all.nl wrote: Is this behaviour of mapnik wanted? As I said: IMHO it is not pleasing to the eye to see the unclassified road rendered on top of the primary_link road. In order of priority, a *_link road is just below its * counterpart but

Re: [OSM-talk] Mapnik rendering issue with *_link roads

That's why you need to know the lower of the two classifications being linked (so you can put the link just under the lower one) On Fri, May 4, 2012 at 4:11 PM, AJ Ashton aj.ash...@gmail.com wrote: On Fri, May 4, 2012 at 8:09 AM, Maarten Deen md...@xs4all.nl wrote: Is this behaviour of mapnik

Re: [OSM-talk] A rendering issue with the maps on OSM homepage?

Op 10-4-2012 17:39, Frank Steggink schreef: On 10-4-2012 15:23, Robert Tromp wrote: Have a look at this area on the west coast of Hokkaido, Japan: http://osm.org/go/7U~IT~Jz Notice the greyed-out ocean and the mis-aligned areas, coastline Looking at the OSM-data itself using JOSM, there seems

[OSM-talk] A rendering issue with the maps on OSM homepage?

Have a look at this area on the west coast of Hokkaido, Japan: http://osm.org/go/7U~IT~Jz Notice the greyed-out ocean and the mis-aligned areas, coastline Looking at the OSM-data itself using JOSM, there seems nothing wrong (other than a few small mapping mishaps) Furthermore, MapOSMatic, for

Re: [OSM-talk] A rendering issue with the maps on OSM homepage?

On 10-4-2012 15:23, Robert Tromp wrote: Have a look at this area on the west coast of Hokkaido, Japan: http://osm.org/go/7U~IT~Jz Notice the greyed-out ocean and the mis-aligned areas, coastline Looking at the OSM-data itself using JOSM, there seems nothing wrong (other than a few small

[OSM-talk] Name rendering on osm.org (was Naming dispute over Jerusalem - OSM failure)

2011/10/5 Ed Loach e...@loach.me.uk: Lambert wrote: Personally I would say:  '.. OFFICIALLY used locally.' Which is where it becomes political... Do you mean officially according to Israel? Or official according to international resolutions such as

Re: [OSM-talk] Name rendering on osm.org (was Naming dispute over Jerusalem - OSM failure)

On Wed, 5 Oct 2011 12:33:25 +0300, pec...@gmail.com wrote: 2011/10/5 Ed Loach e...@loach.me.uk: Lambert wrote: Personally I would say:  '.. OFFICIALLY used locally.' Which is where it becomes political... Do you mean officially according to Israel? Or official according to international

Re: [OSM-talk] Mapnik rendering labels for unrecognised tags

On Tue, Aug 30, 2011 at 12:15 AM, Steve Bennett stevag...@gmail.com wrote: On Tue, Aug 30, 2011 at 12:07 PM, Anthony o...@inbox.org wrote: +1.  While I'd rather see these objects go away altogether, I think a tag of name=Melbourne;Geelong;South-Central NSW Area;Central Victoria Area on a

Re: [OSM-talk] Mapnik rendering labels for unrecognised tags

Anthony wrote: Sounds good. I don't think storing these in OSM, with the non-overlapping tags, is harmful. While I'd love to see them in a separate database or at least a separate layer, the fact of the matter is that separate database and/or separate layer hasn't yet really been implemented.

  1   2   3   4   >