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

[Christian Quest]

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

[Marc_marc]

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 is in a degraded state:
- existing tiles continue to be available
- new tiles and updating existing tile are temporarily stopped

https://github.com/osm-fr/infrastructure/issues/438

Regards,
Marc



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

[OSM-talk] OSM Rendering Server

[Komяpa]

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 sponsoring this machine, drop me
a line and I'll transfer server to your account. I'll stop it in July
otherwise. Monthly fee is 144.2 EUR now.

If you're willing to set up another server (cheaper or on bigger hardware)
side by side, have a look at Hetzner's Server Bidding - you can find
similar machines, without setup fee. Try getting smaller machine with
SSD+HDD and setting SSD as caching device for HDD - it's going to get
better performance than current Vial's setup (which spends lots of time
waiting for HDD).

More on how to provide a server for OSM:
https://wiki.openstreetmap.org/wiki/Servers/Tile_CDN

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

[OSM-talk] Maps rendering forum

[Daniel Koć]

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]


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

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

[Martin Koppenhoefer]

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 protection!" this
> term was used immediately in the same sentence (or in the next one). =} I
> guess they meant "it's voluntary and not formal", but still it's intended
> as a protection of nature, so it's just a special, weak type of protection.
>


the protected area tag definition implies governmental protection, e.g.
there's the sentence: "If there are no results, ask the appropriate
(government) administration". It is unfortunate and must not remain like
this, but it is the current state.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Daniel Koć]

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 lately and now I 
think that local conventions could not be simply translated into 
protection class, so I agree that they are separate probably. For 
example most of national parks in Poland are IUCN class 2, but two of 
them are class 5. See my current report:


https://github.com/gravitystorm/openstreetmap-carto/issues/603#issuecomment-350587768

So now I would not advocate for deprecating "nature_reserve", as this is 
local specific type/name of protected areas. What I still think is 
wrong, is the key "leisure=". I think "boundary=protected_area + 
protected_area=nature_reserve" would be better (we already use such 
scheme for amenity=social_facility for example).



You're basically saying "I care about X, and you care about Y, and my
caring about X is more important, so you are wrong."


I care for proper naming and clear database scheme, not for any 
particular features. Leisure is just a popular activity related to many 
nature reserves, but not for all - think of strict reserves. But all of 
them are meant for nature protection, by design.



That's one person's opinion about some things.  The real world is
complicated and "protected" is very complicated.Certainly around me
there are "wildlife refuges" that allow deer hunting (to protect plants
and toher animals from deer!).


Yes, you are right that there are many views on how the protection is 
implemented. However "protection" is an umbrella term that binds all of 
the nature reserves (including "hunting allowed", "leisure allowed" or 
"voluntary protection"), but "leisure" does not include all of nature 
reserves.



What I don't understand is why you dislike leisure=nature_reserve so
much.  If you want to have boundary=protected_area control the rendering
if both are set, whatever.  But there seems to be some notion that
poeople using that tag causes you trouble, and that you have some basis
to demand that they stop.


Of course I have some trouble, otherwise I wouldn't notice. But that was 
just a trigger to see the real tagging problem, which is bigger than 
just rendering. As I understand you, what you think is "any tag you 
like" is the only policy that really counts, no matter if the scheme is 
precise, coherent and has at least basic classification.


For example I think that:

boundary = protected_area
+ protected_area = nature_reserve/national park/landscape reserve/...
+ protect_class = n

is better than:

leisure = nature_reserve
boundary = national park
boundary = protected_area + protect_class = n

The first one allows to add many properties in a reach and structured 
way, while the second:

- has no hierarchy
- implies "leisure" for every nature reserve
- does not allow to use boundary=national park + 
boundary=protected_area, because they share the same key


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

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

[Greg Troxel]

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.
>
> This way or another it seems to me that leisure= key is wrong and
> using boundary=protected_area (or even just boundary=) is proper.

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.

> Leisure is just a common, but not the inherent property of nature
> reserve - the protection is:

You're basically saying "I care about X, and you care about Y, and my
caring about X is more important, so you are wrong."

I'm not arguing that boundary=protected_area be deprecated or removed.
Just that the existtence of boundary=protected_area does not make
leisure=nature_reserve pointless.

> "Usage of a leisure key, actually, might contradict a protection
> status in a lot of cases, where nature reserve doesn't allow any
> leisure activities. Ownership and enforcement are totally different
> things from protection level. For example, in Russian Federation,
> there are huge state-owned protected areas with limited access
> intended for hunting. They have strict protection enforcement and they
> usually are equal to class 4 or 6. Private hunting lands with similar
> access restriction, management level, and enforcement exist in other
> countries. Someone might argue that if hunting is allowed, it is not a
> protection, but that's just a personal idea of protection."

That's one person's opinion about some things.  The real world is
complicated and "protected" is very complicated.Certainly around me
there are "wildlife refuges" that allow deer hunting (to protect plants
and toher animals from deer!).



What I don't understand is why you dislike leisure=nature_reserve so
much.  If you want to have boundary=protected_area control the rendering
if both are set, whatever.  But there seems to be some notion that
poeople using that tag causes you trouble, and that you have some basis
to demand that they stop.


signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Daniel Koć]

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 wrong and using 
boundary=protected_area (or even just boundary=) is proper.


Leisure is just a common, but not the inherent property of nature 
reserve - the protection is:


"Usage of a leisure key, actually, might contradict a protection status 
in a lot of cases, where nature reserve doesn't allow any leisure 
activities. Ownership and enforcement are totally different things from 
protection level. For example, in Russian Federation, there are huge 
state-owned protected areas with limited access intended for hunting. 
They have strict protection enforcement and they usually are equal to 
class 4 or 6. Private hunting lands with similar access restriction, 
management level, and enforcement exist in other countries. Someone 
might argue that if hunting is allowed, it is not a protection, but 
that's just a personal idea of protection."


[ http://www.openstreetmap.org/user/kocio/diary/42861#comment40293 ]


Agreed.   To me, the real rendering issue si the lack of showing
protected area, and the tendency to show these features by an edge
marking rather than some kind of fill.


There are some tricks to make rendering better and I'm gonna try them, 
but lack of classification of nature reserves is a bigger problem than 
just rendering on osm-carto.


We also use a workaround for airports and it works, but using hacks at 
all means that there is a deeper problem.


With rivers we don't even have a hack and this is the same problem with 
lack of classification for very popular kind of objects.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

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

[Greg Troxel]

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 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.
>
> Presenting leisure=nature_reserve as an 'old scheme' and 'boundary=*' as 
> a 'new scheme' is a serious mischaracterization.  The tags 
> leisure=nature_reserve, boundary=protected_area and 
> boundary=national_park all started being used around the same time.  
> There is no old and new here.
>
> 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.

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.

>> 2. The old scheme is too generic and it causes visual clutter,
>> because all of the protected areas are displayed at once.
>
> That is frankly just nonsense.  If rendering (or not rendering) features 
> with leisure=nature_reserve, boundary=protected_area or 
> boundary=national_park causes visual clutter in a map depends on if and 
> how you render these features.  That is the responsibility of you as a 
> map designer.  Blaming a tagging scheme for not being able to do that 
> without visual clutter is a bit strange.

Agreed.   To me, the real rendering issue si the lack of showing
protected area, and the tendency to show these features by an edge
marking rather than some kind of fill.

>> 3. New scheme has many classes defined, which would allow us to fine
>> tune the rendering (different zoom levels and only some of them).
>
> Have you looked at if these classes are actually used consistently at 
> the moment?  A tagging scheme with ~25 numerical codes as classes with 
> fairly brief and abstract descriptions is not usually destined for 
> success in OSM.

Agreed.


signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Tagging/rendering relations

[Daniel Koć]

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 also wrote the clear TL;DR summary that rendering should 
for now show everything - and then the criticism hit the list, when 
there was not declared to "disappear" anything, let alone over night.


So it has to be something different, I guess, and I still don't know 
what is it?


I don't have a particular idea concerning the orthogonals tags 
mentioned here. But it seems to me they could be discussed better as 
tags in a more general way, then the maintainers of osm-carto could 
propose with their own rendering choice.


That went just like you said: I came with the tagging problem triggered 
by designing rendering, we talked about the tagging problems, and I 
proposed my choice - one for tagging, the second one for rendering.


However it's not that easy nor productive to make everything separate. 
It was parallel discussion in the osm-carto ticket and the arguments 
were not heard on the list. Making more threads doesn't help to 
understand the problem and it's better to avoid it.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

Re: [OSM-talk] Tagging/rendering relations

[Yves]

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 you 
think that?

Because the discussion can be heated by the fear of seeing something 
'disappear' from the map overnight.
I don't have a particular idea concerning the orthogonals tags mentioned here. 
But it seems to me they could be discussed better as tags in a more general 
way, then the maintainers of osm-carto could propose with their own rendering 
choice.
Yves 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Tagging/rendering relations

[Daniel Koć]

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 
relations between tagging and rendering in an acceptable way?


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!


Rendering is my primary motivation to look at these tags and I see 
nothing wrong with being open about it. This is one of many rendering 
styles and one of many uses of OSM data, and data consuming is also 
important thing to consider. Not the most important, but still something 
to think about.


When designing tags we think about different problems - if it's easy for 
a mapper to tag, if the system is coherent, if the names are clear, so 
thinking about classification is equally valid for me - and it's good to 
know why the classification might be needed at all. I don't talk about 
data analysis, because I don't do that, but I suspect classification 
would help that too.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

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

[Yves]

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! 
You should restart this all thread on tagging@ without osm-carto in mind. 
Yves 

Le 3 décembre 2017 04:05:52 GMT+01:00, "Daniel Koć"  a 
écrit :
>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 more precise scheme.
>
>W dniu 01.12.2017 o 01:55, Martin Koppenhoefer pisze:
>
>> there is no problem with 2 different tags fitting for the same kind
>of 
>> thing. These are also different in scope, leisure=nature_reserve is 
>> for all kind of natural protected areas, while
>boundary=protected_area 
>> is for all kind of protected areas.
>
>My general findings are:
>
>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 protection!"
>this 
>term was used immediately in the same sentence (or in the next one). =}
>
>I guess they meant "it's voluntary and not formal", but still it's 
>intended as a protection of nature, so it's just a special, weak type
>of 
>protection.
>
>2. The problem seems to be for a mapper to be more precise, since a 
>typical survey can reveal a sign with a name "XYZ nature reserve". 
>However this is not about just a name.
>
>Boundaries are not visible on the ground easily, so a mapper who draw 
>them have to use some other sources and I believe there are more 
>informations available. Otherwise the area shape is probably not 
>verifiable, which would be bad anyway. And I think all of them are 
>areas, not the points (node would mean probably "here is the protection
>
>area, but exact shape is not shown at the moment"), so boundary is also
>
>a sure thing.
>
>3. The name tag leisure=nature_reserve states that it's about leisure 
>(which of course might be for a given object), but it's always about 
>protection. So even if the value have merits, this key assumption is 
>wrong in general and misses more important property 
>(boundary=nature_reserve has only 35 uses).
>
>4. Another problem is lack of coherent definition of protection other 
>than numbers and high-level classes.
>
>The numbers seems to be derived from IUCN scheme ( 
>https://en.wikipedia.org/wiki/IUCN_protected_area_categories ), but 
>wider: only categories 1-6 is IUCN-based and I don't know about the
>rest.
>
>Especially class 7 is interesting for us: "*nature-feature area*: 
>similar to 4. but /without/ IUCN-level.", so i guess it's for all the 
>non-IUCN classified nature reserves. Probably most of the time this 
>should be clear from the boundary shape source.
>
>It would be good to have more standardized subtags for common features:
>- "nature" - protection_object=* is the same mess as numbers, when 
>talking about hierarchy levels, so maybe some subtag like 
>"nature_reserve=yes" would be useful
>- "private" owner type (not the access type) - 
>governance_type=private_landowner would be great (if really used...)
>- "voluntary" - but that might be clear from the lack of government or 
>international authorities influence
>
>What about the solutions?
>
>> My suggestion for osm carto is to look at both tagging schemes for 
>> nature reserves. I wouldn’t drop support for leisure =nature reserve
>
>In summary, we have 3 popular but overlapping types now:
>
>1. leisure=nature_reserve (77 264)
>2. boundary=national_park (16 583)
>3. boundary=protected_area (62 016)
>
>Their general properties and relations:
>
>1. has a wrong key, but nice value name, and is a subtype of 3.
>2. has a nice value name and a proper key, it's also subtype of 3.
>3. is very broad with precise, but not so common name, it also has 
>subtypes, which are useful for official classification, but are not 
>clear for all the other types of conservation
>
>Therefore I would advice to:
>
>1. Discourage leisure=nature_reserve and make it a subtag of 
>boundary=protected_area, like:
>     a) nature_reserve=yes - 2 uses
>     b) protected_area=nature_reserve - 22 uses
>     c) protected_area=nature - 61 uses
>if needed, otherwise just use a protect_class=7 or other class if
>known.
>
>2. Drop boundary=national_park, since it's easy to identify them all
>and 
>they are equivalent for boundary=protected_area + protect_class=2
>anyway.
>
>That's about cleaning the tagging. For rendering I would show all of 
>them as currently, just using different zoom levels, starting from z8 
>currently (this might change in the future, of 

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

[Daniel Koć]

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 general osm-carto purpose in the link you 
gave is clear about the link between rendering and tagging:


"It's an important feedback mechanism for mappers to validate their 
edits and helps to prevent unfavorable fragmentation of tag use."


[ 
https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md#general-purpose 
]


I'm talking about them on their own merits, because they are autonomous 
parts of OSM "ecosystem", but that doesn't mean they are not connected 
in any way, so I talk about these links too.


It's a simple observation: tagging limits and shapes what we render, 
rendering have an influence on the way we use tags. It's better to be 
aware of it to mitigate "tagging for rendering" (which means *tagging 
the wrong way* just to see something, not the feedback loop!) for example.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

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

[Christoph Hormann]

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 the standard 
style might be entitled to steer the mappers to use a different tagging 
because it is deemed more desirable by you is presumptuous and in clear 
violation of the existing design principles of the style[1].  It is a 
clear case of the tail wagging the dog.

If you want to render/not render certain tags for cartographic reasons 
that is completely up to you.  If you want to point out that 
documentation for certain tags is lacking that is most welcome.  
Likewise if you want to create a proposal to deprecate certain tags and 
replace them by others.  But creating little argument buildings 
attempting to prove certain tags are bad and others are good for the 
sole purpose of justifying rendering decisions that are based on 
wishful thinking that the mappers will adjust to the desires and needs 
of your style to make it work is not acceptable.  Don't do that.

As said before: *do not mix rendering and tagging discussions*.

[1]https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md

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

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

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

[Daniel Koć]

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 more precise scheme.


W dniu 01.12.2017 o 01:55, Martin Koppenhoefer pisze:

there is no problem with 2 different tags fitting for the same kind of 
thing. These are also different in scope, leisure=nature_reserve is 
for all kind of natural protected areas, while boundary=protected_area 
is for all kind of protected areas.


My general findings are:

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 protection!" this 
term was used immediately in the same sentence (or in the next one). =} 
I guess they meant "it's voluntary and not formal", but still it's 
intended as a protection of nature, so it's just a special, weak type of 
protection.


2. The problem seems to be for a mapper to be more precise, since a 
typical survey can reveal a sign with a name "XYZ nature reserve". 
However this is not about just a name.


Boundaries are not visible on the ground easily, so a mapper who draw 
them have to use some other sources and I believe there are more 
informations available. Otherwise the area shape is probably not 
verifiable, which would be bad anyway. And I think all of them are 
areas, not the points (node would mean probably "here is the protection 
area, but exact shape is not shown at the moment"), so boundary is also 
a sure thing.


3. The name tag leisure=nature_reserve states that it's about leisure 
(which of course might be for a given object), but it's always about 
protection. So even if the value have merits, this key assumption is 
wrong in general and misses more important property 
(boundary=nature_reserve has only 35 uses).


4. Another problem is lack of coherent definition of protection other 
than numbers and high-level classes.


The numbers seems to be derived from IUCN scheme ( 
https://en.wikipedia.org/wiki/IUCN_protected_area_categories ), but 
wider: only categories 1-6 is IUCN-based and I don't know about the rest.


Especially class 7 is interesting for us: "*nature-feature area*: 
similar to 4. but /without/ IUCN-level.", so i guess it's for all the 
non-IUCN classified nature reserves. Probably most of the time this 
should be clear from the boundary shape source.


It would be good to have more standardized subtags for common features:
- "nature" - protection_object=* is the same mess as numbers, when 
talking about hierarchy levels, so maybe some subtag like 
"nature_reserve=yes" would be useful
- "private" owner type (not the access type) - 
governance_type=private_landowner would be great (if really used...)
- "voluntary" - but that might be clear from the lack of government or 
international authorities influence


What about the solutions?

My suggestion for osm carto is to look at both tagging schemes for 
nature reserves. I wouldn’t drop support for leisure =nature reserve


In summary, we have 3 popular but overlapping types now:

1. leisure=nature_reserve (77 264)
2. boundary=national_park (16 583)
3. boundary=protected_area (62 016)

Their general properties and relations:

1. has a wrong key, but nice value name, and is a subtype of 3.
2. has a nice value name and a proper key, it's also subtype of 3.
3. is very broad with precise, but not so common name, it also has 
subtypes, which are useful for official classification, but are not 
clear for all the other types of conservation


Therefore I would advice to:

1. Discourage leisure=nature_reserve and make it a subtag of 
boundary=protected_area, like:

    a) nature_reserve=yes - 2 uses
    b) protected_area=nature_reserve - 22 uses
    c) protected_area=nature - 61 uses
if needed, otherwise just use a protect_class=7 or other class if known.

2. Drop boundary=national_park, since it's easy to identify them all and 
they are equivalent for boundary=protected_area + protect_class=2 anyway.


That's about cleaning the tagging. For rendering I would show all of 
them as currently, just using different zoom levels, starting from z8 
currently (this might change in the future, of course):

- z8+: national parks and wilderness areas (both are big by definition)
- z9+: important natural protected areas (class 1-6, with hatched 1a 
probably)

- z10+: other natural protected areas (class 7, maybe also 12, 14 and 97-99)
- z11+: protected areas without class and leisure=nature_reserve

This is just a rough sketch, however it have some nice properties:
- all the existing schemes are visible (boundary=national_park can be 
dropped later)

- more important objects are rendered first
- less precise tagging is rendered late

Another important factor might be 

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

[Andy Townsend]

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:


https://github.com/gravitystorm/openstreetmap-carto/issues/603#issuecomment-347879897 



In short:

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.


(snipped)

Actually one more thing (prompted by SK53 on IRC) - the area of a nature 
reserve is sometimes != the protected area, as noted here:


https://github.com/gravitystorm/openstreetmap-carto/issues/603#issuecomment-348480276

I can think of a few examples locally - one for example is signed as an 
SSSI* but not a nature reserve:


http://www.openstreetmap.org/way/53745064/history

also apparently the "reserve" area at Muston 
http://www.openstreetmap.org/#map=15/52.9219/-0.7766 doesn't match the 
protected area.


Obviously this is orthoganal to what gets rendered and what doesn't, but 
there's certainly a case for using both tags.


Best Regards,
Andy


* Site of Special Scientific Interest.  Probably maps onto a 
"protect_class" or something.



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

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

[Paul Johnson]

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:
>>>
 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
>>> "leisure=nature_reserve" and almost no "boundary=protected_area;
>>> protect_class=XYZ".  The reason is simple - nature reserves where I'm
>>> likely to be mapping often have a sign saying "XYZ nature reserve".  There
>>> isn't going to be a sign helping me work out what "protect_class" in OSM it
>>> is, so that doesn't get mapped.  It's also nothing to do with "what gets
>>> rendered"; I actually render my own maps and map quite a lot of stuff that
>>> isn't displayed there :)
>>>
>>
>> Seems like it wouldn't be too difficult to consider the two as equivalent.
>>
>
> Not exactly. Some protected areas are cultural/social/heritage protected
> areas. Specifically those tagged with protect_class=21 to 29.
>

I meant the specific protect_class tags referring to nature preserves
specifically.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Eugene Alvin Villar]

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 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
>> "leisure=nature_reserve" and almost no "boundary=protected_area;
>> protect_class=XYZ".  The reason is simple - nature reserves where I'm
>> likely to be mapping often have a sign saying "XYZ nature reserve".  There
>> isn't going to be a sign helping me work out what "protect_class" in OSM it
>> is, so that doesn't get mapped.  It's also nothing to do with "what gets
>> rendered"; I actually render my own maps and map quite a lot of stuff that
>> isn't displayed there :)
>>
>
> Seems like it wouldn't be too difficult to consider the two as equivalent.
>

Not exactly. Some protected areas are cultural/social/heritage protected
areas. Specifically those tagged with protect_class=21 to 29.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Paul Johnson]

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 to make it visible on default map.
>>
>
> Just to chuck one example in - I've tagged lots of
> "leisure=nature_reserve" and almost no "boundary=protected_area;
> protect_class=XYZ".  The reason is simple - nature reserves where I'm
> likely to be mapping often have a sign saying "XYZ nature reserve".  There
> isn't going to be a sign helping me work out what "protect_class" in OSM it
> is, so that doesn't get mapped.  It's also nothing to do with "what gets
> rendered"; I actually render my own maps and map quite a lot of stuff that
> isn't displayed there :)
>

Seems like it wouldn't be too difficult to consider the two as equivalent.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Martin Koppenhoefer]

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 you detect such a hack then?
> 
> In my opinion 31k is a serious amount (about a half of both) that is a strong 
> suggestion of the problem, at least.


there is no problem with 2 different tags fitting for the same kind of thing. 
These are also different in scope, leisure=nature_reserve is for all kind of 
natural protected areas, while boundary=protected_area is for all kind of 
protected areas. It appears to be very detailed at first glance, but if you 
look at the actual tagging almost one third misses the most basic information 
(protect_class) and the long list of additional tags suggested in the wiki 
contains some questionable items and instructions. E.g. protection_aim, 
protection_ban and protection_instructions don’t seem to be suitable for a tag 
value, even more as it is not documented how to apply them.
E.g. protection_object: the wiki says it should describe what is protected (but 
not in detail, says again the wiki: “Preferably don´t list species or elements 
- therefor you should give a website-url.”), in actual values “recreation” is 
leading, second is “timber”: 
https://taginfo.openstreetmap.org/keys/protection_object#values
valid_from is a rarely used duplicate of start_date, etc.

My suggestion for osm carto is to look at both tagging schemes for nature 
reserves. I wouldn’t drop support for leisure =nature reserve 


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

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

[ajt1...@gmail.com]

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 
"leisure=nature_reserve" and almost no "boundary=protected_area; 
protect_class=XYZ".  The reason is simple - nature reserves where I'm 
likely to be mapping often have a sign saying "XYZ nature reserve".  
There isn't going to be a sign helping me work out what "protect_class" 
in OSM it is, so that doesn't get mapped.  It's also nothing to do with 
"what gets rendered"; I actually render my own maps and map quite a lot 
of stuff that isn't displayed there :)


Best Regards,

Andy




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

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

[Daniel Koć]

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 opinion 31k is a serious amount (about a half of both) that is a 
strong suggestion of the problem, at least.



That is frankly just nonsense.  If rendering (or not rendering) features
with leisure=nature_reserve, boundary=protected_area or
boundary=national_park causes visual clutter in a map depends on if and
how you render these features.  That is the responsibility of you as a
map designer.  Blaming a tagging scheme for not being able to do that
without visual clutter is a bit strange.


It's easy - with leisure=nature_reserve you don't have any 
classification system, so you have less tools to make a proper rendering 
decisions. The other solution is guessing or accepting the mess, which 
are poor options for me.



Have you looked at if these classes are actually used consistently at
the moment?  A tagging scheme with ~25 numerical codes as classes with
fairly brief and abstract descriptions is not usually destined for
success in OSM.


We don't need to check every single one of them, probably just selecting 
a nature related subset of them would be enough. Not everything should 
be rendered (like "community life" or "earth-moving area") and even just 
selecting national parks from the rest would be clear win for a start.



4. The new scheme looks like more general than the old one, so it's
all that's we really need.

Which is just another way of saying boundary=protected_area is much less
meaningful than leisure=nature_reserve since the latter at least
specifies it is nature protection while the former does not.


Just look at the classification, there's a cluster of such classes:

https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area#Nature-protected-area


You are also contradicting yourself here - in 2. you say "the old scheme
is too generic" and here you say "the new scheme looks like more
general" - which is it?


By "generic" I mean "lacking details", which is bad.
By "general" I mean "encompassing all of this and more", which is good.


but then drop arguing for certain tagging
ideas based on your perceived needs for rendering.  Tagging decisions
should be based on how mappers can best document their knowledge about
the geography.  Not on what some developers find convenient for
rendering.


In my opinion there's a better tagging scheme for documenting that 
knowledge, that's why I suggested deprecation. But that is just the 
opening of discussion, not the final solution.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

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

[Paul Johnson]

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:
>
> https://github.com/gravitystorm/openstreetmap-carto/issues/
> 603#issuecomment-347879897
>
> In short:
>
> 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.
>
> 2. The old scheme is too generic and it causes visual clutter, because all
> of the protected areas are displayed at once.
>
> 3. New scheme has many classes defined, which would allow us to fine tune
> the rendering (different zoom levels and only some of them).
>
> 4. The new scheme looks like more general than the old one, so it's all
> that's we really need.
>
> Therefore I think rendering of leisure=nature_reserve should be dropped on
> osm-carto, so boundary=* would take over. In this case the areas should be
> tagged with a new scheme to be visible there. That might lead to
> deprecation of leisure=nature_reserve in the future.


 I'm OK with this.  I wouldn't mind some kind of subtle fill where
appropriate.  Class 24 areas probably should render something closer to
administrative boundaries currently do.  Any hatch in that case would need
to be insanely subtle in order to not overwhelm other areas that have
hatches or it'd just make a real mess of things in the western US
(especially in my area where it's a 2-3 hour drive in the shortest
direction to leave such a region).
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Christoph Hormann]

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 highly questionable.  More details on that in the 
following.

> 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.

Presenting leisure=nature_reserve as an 'old scheme' and 'boundary=*' as 
a 'new scheme' is a serious mischaracterization.  The tags 
leisure=nature_reserve, boundary=protected_area and 
boundary=national_park all started being used around the same time.  
There is no old and new here.

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.

> 2. The old scheme is too generic and it causes visual clutter,
> because all of the protected areas are displayed at once.

That is frankly just nonsense.  If rendering (or not rendering) features 
with leisure=nature_reserve, boundary=protected_area or 
boundary=national_park causes visual clutter in a map depends on if and 
how you render these features.  That is the responsibility of you as a 
map designer.  Blaming a tagging scheme for not being able to do that 
without visual clutter is a bit strange.

> 3. New scheme has many classes defined, which would allow us to fine
> tune the rendering (different zoom levels and only some of them).

Have you looked at if these classes are actually used consistently at 
the moment?  A tagging scheme with ~25 numerical codes as classes with 
fairly brief and abstract descriptions is not usually destined for 
success in OSM.

> 4. The new scheme looks like more general than the old one, so it's
> all that's we really need.

Which is just another way of saying boundary=protected_area is much less 
meaningful than leisure=nature_reserve since the latter at least 
specifies it is nature protection while the former does not.

You are also contradicting yourself here - in 2. you say "the old scheme 
is too generic" and here you say "the new scheme looks like more 
general" - which is it?

On a general note: Please do not mix tagging discussions and rendering 
discussions - that is a recipe for desaster.  If rendering 
considerations lead you to realize tagging issues and you want to 
discuss those that is fine but then drop arguing for certain tagging 
ideas based on your perceived needs for rendering.  Tagging decisions 
should be based on how mappers can best document their knowledge about 
the geography.  Not on what some developers find convenient for 
rendering.

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

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

[OSM-talk] Planned rendering changes of protected areas

[Daniel Koć]

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:


https://github.com/gravitystorm/openstreetmap-carto/issues/603#issuecomment-347879897

In short:

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.


2. The old scheme is too generic and it causes visual clutter, because 
all of the protected areas are displayed at once.


3. New scheme has many classes defined, which would allow us to fine 
tune the rendering (different zoom levels and only some of them).


4. The new scheme looks like more general than the old one, so it's all 
that's we really need.


Therefore I think rendering of leisure=nature_reserve should be dropped 
on osm-carto, so boundary=* would take over. In this case the areas 
should be tagged with a new scheme to be visible there. That might lead 
to deprecation of leisure=nature_reserve in the future.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

Re: [OSM-talk] Ravines rendering in Mapnik

[Martin Koppenhoefer]

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 blue.



thank you for reporting it, the style team is already aware of this problem and 
it will be fixed soon...


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

[OSM-talk] Ravines rendering in Mapnik

[Javier Sánchez Portero]

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.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Glenn Plas]

On 29-07-16 11:50, Bart Van Lancker wrote:
> Hoi iedereen,
> 
> Ik ben dus degene die gepoogd had de Leie te fixen. Even opmerken dat begin 
> juni  het hele deel tussen Deinze en de Franse grens niet renderde, en dat 
> het Buda-eiland in Kortrijk onder water stond.
> Ik heb daarom de riverbank opgesplitst in verschillende stukken, en dat 
> leverde correcte rendering op tot en met Kortrijk.
> Ik had dit twee jaar eerder ook al zo gedaan voor het deel tussen Gent en 
> Deinze en dat werkte goed.
> Het deel van Kortrijk tot Wervik bleef inderdaad blanco, en ik wist niet 
> waarom. Nu is het blijkbaar in orde, bedankt daarvoor !


Mercie voor de uitleg.  Zoals altijd hier : Don't fix the blame, fix the
problem.

Denk dat niemand hier met slijk zal smijten en het digitaal gaat
overleven.   Je gaat van mij ook een pak fouten vinden, ik vind
wekelijks dingen van mezelf terug waarvan ik denk: waar was je toen mee
bezig !?!

Dus, maw: het was bijna allemaal ok, buiten dit kleine stukje.

Blijf trouwens goeie changeset comments geven, heel handig en belangrijk
om de context van de edits te snappen.

Mvg,

Glenn

> 
> -Oorspronkelijk 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.openstreetmap.org/way/423643352/history
> 
> De comment van Jol dan. "Poging tot fix riverbank Leie"  -> denk dat Ruben 
> dat dus goed heeft ingeschat.
> 
> +1 trouwens voor goede changeset comments, ook al was het maar een 
> +poging
> 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


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

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

[Bart Van Lancker]

Hoi iedereen,

Ik ben dus degene die gepoogd had de Leie te fixen. Even opmerken dat begin 
juni  het hele deel tussen Deinze en de Franse grens niet renderde, en dat het 
Buda-eiland in Kortrijk onder water stond.
Ik heb daarom de riverbank opgesplitst in verschillende stukken, en dat leverde 
correcte rendering op tot en met Kortrijk.
Ik had dit twee jaar eerder ook al zo gedaan voor het deel tussen Gent en 
Deinze en dat werkte goed.
Het deel van Kortrijk tot Wervik bleef inderdaad blanco, en ik wist niet 
waarom. Nu is het blijkbaar in orde, bedankt daarvoor !

-Oorspronkelijk 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.openstreetmap.org/way/423643352/history

De comment van Jol dan. "Poging tot fix riverbank Leie"  -> denk dat Ruben dat 
dus goed heeft ingeschat.

+1 trouwens voor goede changeset comments, ook al was het maar een 
+poging



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

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

[Sander Deryckere]

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 describe the river, not the
riverbank. And a riverbank isn't a waterway either (you navigate the river,
not the bank). It even causes some problems, like when you want to measure
the total length of waterways in an area, you have to exclude this strange
case.

So I would prefer to just rename all waterway=riverbank tags to
natural=water+water=river. But sadly, the term riverbank has also been used
for canals and streams (which sounds totally bonkers to me), so such a
conversion isn't possible when done manually.

The page describing the water=* tags also says nothing about using multi
polygons. It's just as fine to use natural=water on river segments.

So in short, I don't get why there are people who want to keep that
awkwardly named tag .

Regards,
Sander
Op 29-jul.-2016 00:09 schreef "Ruben Maes" :

> 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
> http://osm.org/relation/2393380:
>
> * http://osm.org/relation/2393380#map=17/50.89599/3.34545
>The sluice was a complete mess. It took me some time to figure out what
> was going on exactly here.
>
> * http://osm.org/changeset/41095237#map=19/50.92122/3.42972
>There was a random tiny, excess way in the relation.
>
> The waterway=riverbank tags were non-uniformly applied. Not all ways had
> them, some had an additional random area=yes or area=no. Some had
> natural=riverbank, waterway=canalbank or some other weird derivation I had
> never heard of.
> I stripped those completely. No more waterway=riverbank on this part of
> the Leie [note 1]. But if some day consensus is reached (not that that will
> ever happen) that the multipolygon approach with {natural=water,
> water=river} isn't good after all, it wouldn't be so hard to convert it.
>
> [note 1] Sorry Glenn, I really couldn't be bothered any more. With a
> relation, I can tell JOSM to fetch all member ways, use webtools like the
> one you mentioned to check their integrity, and the JOSM validator will
> complain if I'm messing up.
>
> --
> Dit bericht is ondertekend met OpenPGP.
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Ruben Maes]

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 
http://osm.org/relation/2393380:

* http://osm.org/relation/2393380#map=17/50.89599/3.34545
   The sluice was a complete mess. It took me some time to figure out what was 
going on exactly here.

* http://osm.org/changeset/41095237#map=19/50.92122/3.42972
   There was a random tiny, excess way in the relation.

The waterway=riverbank tags were non-uniformly applied. Not all ways had them, 
some had an additional random area=yes or area=no. Some had natural=riverbank, 
waterway=canalbank or some other weird derivation I had never heard of.
I stripped those completely. No more waterway=riverbank on this part of the 
Leie [note 1]. But if some day consensus is reached (not that that will ever 
happen) that the multipolygon approach with {natural=water, water=river} isn't 
good after all, it wouldn't be so hard to convert it.

[note 1] Sorry Glenn, I really couldn't be bothered any more. With a relation, 
I can tell JOSM to fetch all member ways, use webtools like the one you 
mentioned to check their integrity, and the JOSM validator will complain if I'm 
messing up.

-- 
Dit bericht is ondertekend met OpenPGP.

signature.asc
Description: This is a digitally signed message part.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Glenn Plas]

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 toch ergens een "howto" of
> een "preferred practice" zijn voor het mappen van een courant en
> essentieel landschapselement als een rivier?

Die zijn er op de wiki maar vaak groeit het historisch, ooit was er maar
1 aanpak, en die bleek dan de lading niet helemaal te dekken, en dan
komt er een proposal en een 2de aanpak. (of een 3de, 4de ...)

Vandaar dat er vaak moet over gepraat worden, per streek/land komt er
dan nog eens lokale gewoontes bij te kijken.

> 
> Enne, jawel, het ging er me over dat er op tijd van enkele uren galant
> een twintigtal berichten rondgingen met evenzovele meningen of toch
> minstens ideeën. Ik had verwacht dat binnen de kortste keren iemand had
> verwezen naar "How to map rivers, streams, and other natural flows of
> surface waters". Meer dient er toch niet gezegd?

Ik vond het een gezonde discussie, en ja... mailing lists zijn soms
slapend en dan plots heel actief.  Niet echt abnormaal.  Het is ook
altijd goed om naast uw eigen idee ook eens een andere insteek te horen,
al is het maar om men eigen mening te toetsen aan die van de rest.  Ik
leer er altijd uit.

Maar to the point: de tagging schema's zijn er op de wiki:
water=* , waterway=* en natural=water zijn er een paar voor waterpret.

> En inderdaad, met de technische details van het mappen wil ik me niet
> inlaten, ik heb enkel een klein beetje zicht op het mappen van
> vliegvelden, euh, "luchtvaarttereinen" :) Maar ik stelde me toch wat
> vragen bij onze aanpak oftewel metodiek, ik begin zo'n beetje ambitie te
> krijgen in de richting van projectbegeleiding... ;)

Beste dat je kan doen -denk ik toch- is al het engelstalige op de wiki
naar nederlands/frans te 'porten' met de lokale gewoontes in acht te
nemen.  Ik geef toe dat het is zoals lego: je moet de stukjes zelf bij
elkaar zoeken, in die zin is er geen 'enige pagina' die alles behandelt,
helaas een feit.

Wat Ruben ook ervaart is dat je echt wel enorm veel tijd steekt in
relations te fixen en je kan bijna niet anders dan dit in JOSM te doen.

Je zou ook de digests kunnen nemen ipv elke mail.  Ik raad alleszins aan
om rules in je mail(client) te gebruiken om de dingen te sorteren.

De taggin lijst is best wel een grappige suggestie van Ruben :) OSM humor...

Ik ben ook fan van de dingen gewoon consequent te doen ipv alles om te
gooien.

Wat ik trouwens wel een grappige changeset comment vind is de
problematische way : https://www.openstreetmap.org/way/423643352/history

De comment van Jol dan. "Poging tot fix riverbank Leie"  -> denk dat
Ruben dat dus goed heeft ingeschat.

+1 trouwens voor goede changeset comments, ook al was het maar een poging

Glenn

> 
> Karel
> 
> 
> On 28-07-16 20:25, Glenn Plas wrote:
>> On 28-07-16 22:16, Karel Adams wrote:
>>> 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 *)
>> Wat is uw definitie van 'veel' ?  Beetje vage klacht.  Gaat het over het
>> aantal mails, hoeveel we in de mails zetten.  Ik faal te begrijpen wat
>> veel is in deze context.
>>
>>> Waarom zou die Leie anders gemapt worden dan de Rijn of de Seine of de
>>> Nete, Klein of Groot?
>> Goeie vraag, daarom dat we dit recht willen zetten.  De Nete is net
>> hetzelfde gemapt (in Duffelse dan) als ik voorstel en hoe de Zenne is
>> gemapt voor het merendeel.  Wat ze daar bij de Leie hebben gedaan is een
>> mix van vanalles, een relatie die overbodig is en een aantal fouten in
>> OSM die eruit mogen/moeten.
>>
>>> Verder bemoei ik me niet met de discussie, ze gaat duidelijk mijn petje
>>> te boven.
>> Beetje raar om als reactie te vermelden dat je verder niet gaat reageren
>> omdat je niet weet waarover het gaat, niet ?
>>
>> Glenn
>>
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be


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

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

[Ruben Maes]

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 enkele uren galant 
> een twintigtal berichten rondgingen met evenzovele meningen of toch 
> minstens ideeën. Ik had verwacht dat binnen de kortste keren iemand had 
> verwezen naar "How to map rivers, streams, and other natural flows of 
> surface waters". Meer dient er toch niet gezegd?

Welkom bij OpenStreetMap. Dat is dus totaal niet het geval hier. :p

Als je wat minder van dit soort discussies, en wat minder hevig wil, en wat 
minder berichten snel op elkaar, raad ik je aan je te abonneren op de 
Tagging-mailing-list.

(Voor alle duidelijkheid: dat was anti-advies. Ik sta niet in voor de gevolgen 
als je dat doet.)

> En inderdaad, met de technische details van het mappen wil ik me niet 
> inlaten, ik heb enkel een klein beetje zicht op het mappen van 
> vliegvelden, euh, "luchtvaarttereinen" :) Maar ik stelde me toch wat 
> vragen bij onze aanpak oftewel metodiek, (...)

Ik ook, ik wens wel eens dat er een authoriteit was, dan werd er niet zoveel 
tijd aan dit soort dingen verspild. Want inderdaad maakt het niet zo heel veel 
uit, zo lang het maar een beetje consequent is. Dat consequent krijgen is dus 
het moeilijkst aangezien iedereen zijn eigen ding wil doen. :p


signature.asc
Description: This is a digitally signed message part.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Karel Adams]

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 enkele uren galant 
een twintigtal berichten rondgingen met evenzovele meningen of toch 
minstens ideeën. Ik had verwacht dat binnen de kortste keren iemand had 
verwezen naar "How to map rivers, streams, and other natural flows of 
surface waters". Meer dient er toch niet gezegd?


En inderdaad, met de technische details van het mappen wil ik me niet 
inlaten, ik heb enkel een klein beetje zicht op het mappen van 
vliegvelden, euh, "luchtvaarttereinen" :) Maar ik stelde me toch wat 
vragen bij onze aanpak oftewel metodiek, ik begin zo'n beetje ambitie te 
krijgen in de richting van projectbegeleiding... ;)


Karel


On 28-07-16 20:25, Glenn Plas wrote:

On 28-07-16 22:16, Karel Adams wrote:

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 *)

Wat is uw definitie van 'veel' ?  Beetje vage klacht.  Gaat het over het
aantal mails, hoeveel we in de mails zetten.  Ik faal te begrijpen wat
veel is in deze context.


Waarom zou die Leie anders gemapt worden dan de Rijn of de Seine of de
Nete, Klein of Groot?

Goeie vraag, daarom dat we dit recht willen zetten.  De Nete is net
hetzelfde gemapt (in Duffelse dan) als ik voorstel en hoe de Zenne is
gemapt voor het merendeel.  Wat ze daar bij de Leie hebben gedaan is een
mix van vanalles, een relatie die overbodig is en een aantal fouten in
OSM die eruit mogen/moeten.


Verder bemoei ik me niet met de discussie, ze gaat duidelijk mijn petje
te boven.

Beetje raar om als reactie te vermelden dat je verder niet gaat reageren
omdat je niet weet waarover het gaat, niet ?

Glenn



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



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

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

[Ruben Maes]

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.
> > 
> > Well that's weird, because there's a canal connected to the river and it 
> > also needs cleaning, and we have'd to use two fundamentally different ways 
> > to map that.
> 
> Oh, I see what you mean I think, the U detour.. interesting.
> 
> http://www.openstreetmap.org/relation/1201127#map=16/50.9146/3.4226=N
> 
> That piece seems seriously broken (visual inspection).  But this is
> probably the 'canal' you talk about.

Yes, the Ooigem Sluice is broken badly. I'm fixing it up right now. The canal I 
was talking about is indeed the canal Roeselare-Ooigem, which joins the Leie in 
said sluice.

> Glenn
> 
> 
> > 
> >> (...)
> >> If you want to take a stab at fixing it , go ahead. If you want me to
> >> review it later on, give me the headsup and I'll take a look.  A bit
> >> short in time due to closing the books on the fiscal year of 2015.  I
> >> hate fines :)
> > 
> > I'll try my best. In fact I have been working on it for several hours, but 
> > then you came along here on the list opening the discussion. (but that's 
> > alright) ;)
> > 
> > 
> > 
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> > 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


-- 
Dit bericht is ondertekend met OpenPGP.

signature.asc
Description: This is a digitally signed message part.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Glenn Plas]

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 river and it also 
> needs cleaning, and we have'd to use two fundamentally different ways to map 
> that.

Oh, I see what you mean I think, the U detour.. interesting.

http://www.openstreetmap.org/relation/1201127#map=16/50.9146/3.4226=N

That piece seems seriously broken (visual inspection).  But this is
probably the 'canal' you talk about.

Glenn


> 
>> (...)
>> If you want to take a stab at fixing it , go ahead. If you want me to
>> review it later on, give me the headsup and I'll take a look.  A bit
>> short in time due to closing the books on the fiscal year of 2015.  I
>> hate fines :)
> 
> I'll try my best. In fact I have been working on it for several hours, but 
> then you came along here on the list opening the discussion. (but that's 
> alright) ;)
> 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


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

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

[Karel Adams]

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 mijn petje 
te boven.


Karel

*cfr Dirk Van Esbroeck op tekst van Richard Minne:
De Leie en lijkt ons maar een landelijk rivierken
Een wandelende streep, en wat traag water toe
Met aan iederen draai een waaiend populierken
Een half-verdronken ponte, een schilder en een koe


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

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

[Ruben Maes]

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 pond, stream, river, canal, oxbow, etc.
> etc. [1] carto-css (the standard rendering can handle this tagging
> scheme without problems).
> 
> Recently someone was complaining about this use for bassins. [2]
> 
> [1] http://wiki.openstreetmap.org/wiki/Key:water
> [2] https://lists.openstreetmap.org/pipermail/talk/2016-June/076144.html

In the thread that followed several points for both sides have been made.

Reading the full thread on talk, I don't feel like fixing the Leie any more. I 
will just try to solve the render issues and then leave it be. OSM's free 
tagging is one of it's strengths, but also one of it's biggest disadvantages.

-- 
Dit bericht is ondertekend met OpenPGP.

signature.asc
Description: This is a digitally signed message part.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Ruben Maes]

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 have'd to use two fundamentally different ways to map 
that.

> (...)
> If you want to take a stab at fixing it , go ahead. If you want me to
> review it later on, give me the headsup and I'll take a look.  A bit
> short in time due to closing the books on the fiscal year of 2015.  I
> hate fines :)

I'll try my best. In fact I have been working on it for several hours, but then 
you came along here on the list opening the discussion. (but that's alright) ;)

-- 
Dit bericht is ondertekend met OpenPGP.

signature.asc
Description: This is a digitally signed message part.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Glenn Plas]

-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
> waterway=riverbank says: "This describes the tagging scheme for
> large rivers", linking to the Wikipedia page for river: "A river is
> a natural flowing watercourse ..."

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.

> waterway=riverbank is less relation-fiddling and I'm starting to
> see the advantages of that as well.

I had to fix the Zenne so many times that I started to see the merits
of this as well.  I actually just discovered why this wasn't rendering
in the first place, there is some overlaying going on.

Check the relation 2393380 here:
http://analyser.openstreetmap.fr/cgi-bin/index.py

The top 2 yellow markers show you where there is a duplicate way and
it's in the relation:

https://www.openstreetmap.org/way/423643352

That small piece is preventing it from being rendered decently at the
moment.

If you want to take a stab at fixing it , go ahead. If you want me to
review it later on, give me the headsup and I'll take a look.  A bit
short in time due to closing the books on the fiscal year of 2015.  I
hate fines :)

Glenn


> 
> On donderdag 28 juli 2016 21:19 Glenn Plas wrote:
>> 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 are equally hard to maintain.
>> 
>> I disagree here.  Riverbank is easy to maintain for me atleast,
>> they should not be included in any relationship either, they
>> should not be named and they do make sense on rivers where the
>> waterlevel (and/or tides) influence the shape. [1]
>> 
>> The logical riverway still belongs in the the 'waterway tagging
>> scheme' if we can call it like that.
>> 
>> natural=water isn't meant for rivers.  I don't see where this
>> idea is coming from at the moment.  It's used on lakes, still
>> water etc but on a river it's not suited. [2]  The wiki doesn't
>> mention that usage either.
>> 
>> So the logical river would be waterway=river , and that is the
>> part you would put in a waterway relation, the riverbank not.
>> 
>> Keep things simple I would suggest.  Hence the suggestion to
>> delete the relation, probably have to review the tags first so we
>> don't throw away good information.
>> 
>> Now, I'm about to put the kids to bed so I really just scanned
>> the wiki but I've done quite some research on waterway logic,
>> hence why I'm quite convinced.  But always open to suggestions.
>> 
>> Glenn
>> 
>> 
>> 
>> [1] http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank 
>> [2] http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater
> 
> 
> 
> 
> ___ Talk-be mailing
> list Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXmmOJAAoJELTQZq3fHKRZxscP/RwzPDRAUyhOMBaGHzIoL4R4
YOgDqsMhqUUsIUQQJxVg8zOn2qpKM7OwRZyGSw1+QrG96h1SsAv1v8FeksWsM5t2
XuLqKN8FBhEWmPhMjSwvlS+yHMlEBnghmkfEjQHPGs1Y1JGv9G0l2oMFNBv5fdTm
kGCA5uYqDbXjxnJRuSv1qGe/NMt0BwOmbDMYTPiNGPNEFxFa/OGN72rrgopUSPJH
9K8gKGsL3fqqFvcibPHc5TO7stUGRo0sjaxJdIEHtVoUd5ZOg+1tOY3KVcnWefTZ
rk4HLk2y5qjsyYwsnFHc+GgURjS1QzRDqioVAjOWvQXuBGaWsBrYnO0JSgJXAyNl
h9ShtFUnQ7NGbFWuRqPmpDyWJzliUMEBtAq/LgqdPUShf3fTEIcL19b9D/v+pPPw
lJH1V1WzudJboQX2fDD4MqN2Heh3IatRYv5tb6LWkaoxt1SjkIR5gKCbR0KiM7Ve
Fb3vKVv8xl58R6mEE2hF09PAp8QEtUnc8NxDNptylyfaniP9nUCM+/A+1vWn3leS
5+k2VNLWO4p3dXzP+2yUJlUrmBT46kOh4s9QvaEiumxeZJ7rrd2p3MeTfBz5UBEc
Qz5XZrJ3Uhf5/jYOkwppFCm69fBI3eWjhjuFtYjSOlDlxNS7Fi4pLcMm4HMS5Utm
9ROn5Vn/iIVFOh5O5oy5
=hCmV
-END PGP SIGNATURE-

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

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

[Marc Gemis]

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 (the standard rendering can handle this tagging
scheme without problems).

Recently someone was complaining about this use for bassins. [2]

[1] http://wiki.openstreetmap.org/wiki/Key:water
[2] https://lists.openstreetmap.org/pipermail/talk/2016-June/076144.html

On Thu, Jul 28, 2016 at 9:42 PM, 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 waterway=riverbank says: "This 
> describes the tagging scheme for large rivers", linking to the Wikipedia page 
> for river: "A river is a natural flowing watercourse ..."
>
> waterway=riverbank is less relation-fiddling and I'm starting to see the 
> advantages of that as well.
>
> On donderdag 28 juli 2016 21:19 Glenn Plas wrote:
>> 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 are equally hard to maintain.
>>
>> I disagree here.  Riverbank is easy to maintain for me atleast, they
>> should not be included in any relationship either, they should not be
>> named and they do make sense on rivers where the waterlevel (and/or
>> tides) influence the shape. [1]
>>
>> The logical riverway still belongs in the the 'waterway tagging scheme'
>> if we can call it like that.
>>
>> natural=water isn't meant for rivers.  I don't see where this idea is
>> coming from at the moment.  It's used on lakes, still water etc but on a
>> river it's not suited. [2]  The wiki doesn't mention that usage either.
>>
>> So the logical river would be waterway=river , and that is the part you
>> would put in a waterway relation, the riverbank not.
>>
>> Keep things simple I would suggest.  Hence the suggestion to delete the
>> relation, probably have to review the tags first so we don't throw away
>> good information.
>>
>> Now, I'm about to put the kids to bed so I really just scanned the wiki
>> but I've done quite some research on waterway logic, hence why I'm quite
>> convinced.  But always open to suggestions.
>>
>> Glenn
>>
>>
>>
>>  [1] http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank
>>  [2] http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater
>
>
> --
> Dit bericht is ondertekend met OpenPGP.
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

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

[Ruben Maes]

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 Wikipedia page for river: 
"A river is a natural flowing watercourse ..."

waterway=riverbank is less relation-fiddling and I'm starting to see the 
advantages of that as well.

On donderdag 28 juli 2016 21:19 Glenn Plas wrote:
> 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 are equally hard to maintain.
> 
> I disagree here.  Riverbank is easy to maintain for me atleast, they
> should not be included in any relationship either, they should not be
> named and they do make sense on rivers where the waterlevel (and/or
> tides) influence the shape. [1]
> 
> The logical riverway still belongs in the the 'waterway tagging scheme'
> if we can call it like that.
> 
> natural=water isn't meant for rivers.  I don't see where this idea is
> coming from at the moment.  It's used on lakes, still water etc but on a
> river it's not suited. [2]  The wiki doesn't mention that usage either.
> 
> So the logical river would be waterway=river , and that is the part you
> would put in a waterway relation, the riverbank not.
> 
> Keep things simple I would suggest.  Hence the suggestion to delete the
> relation, probably have to review the tags first so we don't throw away
> good information.
> 
> Now, I'm about to put the kids to bed so I really just scanned the wiki
> but I've done quite some research on waterway logic, hence why I'm quite
> convinced.  But always open to suggestions.
> 
> Glenn
> 
> 
> 
>  [1] http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank
>  [2] http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater


-- 
Dit bericht is ondertekend met OpenPGP.

signature.asc
Description: This is a digitally signed message part.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Glenn Plas]

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 are equally hard to maintain.

I disagree here.  Riverbank is easy to maintain for me atleast, they
should not be included in any relationship either, they should not be
named and they do make sense on rivers where the waterlevel (and/or
tides) influence the shape. [1]

The logical riverway still belongs in the the 'waterway tagging scheme'
if we can call it like that.

natural=water isn't meant for rivers.  I don't see where this idea is
coming from at the moment.  It's used on lakes, still water etc but on a
river it's not suited. [2]  The wiki doesn't mention that usage either.

So the logical river would be waterway=river , and that is the part you
would put in a waterway relation, the riverbank not.

Keep things simple I would suggest.  Hence the suggestion to delete the
relation, probably have to review the tags first so we don't throw away
good information.

Now, I'm about to put the kids to bed so I really just scanned the wiki
but I've done quite some research on waterway logic, hence why I'm quite
convinced.  But always open to suggestions.

Glenn



 [1] http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank
 [2] http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater

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

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

[Ruben Maes]

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 tried to migrate to the natural=water scheme but
> > didn't remove the waterway=riverbank.
> 
> We should keep waterway=riverbank, and delete relation 2393380
> altogether, it contains highway=paths and all sorts of stuff that
> doesn't belong there.   There are seperated sections and also admin
> boundaries that totally do not belong in a waterway.
> 
> 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 are equally hard to maintain.

IMO the multipolygon with natural=water is more logical. The riverbank approach 
is weird, even though it has been used longer.

> >> Als ik straks ga meten hoelang de Leie is adhv. deze data gaat
> >> dit niet juist zijn.
> >
> > Obviously you should measure the type=waterway relation[2], not the
> > type=multipolygon relation[1].
> 
> Sure, but what if I want to do it by name only, without tagging scheme
> quirks.
> 
> There is no need for 2 relations, period.  "There can be... only one!"
> 
> Glenn
> 
> 
> 
> 
> >
> > [1]
> >> https://www.openstreetmap.org/relation/1201127
> >>
> >> en
> >
> > [2]
> >> https://www.openstreetmap.org/relation/2393380
> >>
> >> Er klopt ook nog steeds iets niet in die relaties/ways, als je
> >> die links opendoet zie je het zo al.
> >>
> >> Glenn
> >>
> >>
> >> On 28-07-16 18:00, Ruben Maes wrote:
> >>> Hi Frank
> >>>
> >>> I've removed the area=no that was tagged on it. I think that
> >>> was the cause, I hope it renders again soon.
> >>>
> >>> On donderdag 28 juli 2016 17:54 Jakka wrote:
>  Hi
> 
>  A note that the rendering of riverbank "Leie" between
>  Kortrijk and Wervik is gone. In the past I added a lot of
>  stuff there and it was good. Had corrected several overlap
>  riverbanks en controlled begin to end but I do not know what
>  to look after. The "Leie" is a natural border with France Has
>  there been a mass update from there ?
> 
>  Some one with knowledge can check that?
> 
>  https://www.openstreetmap.org/note/646584#map=17/50.82877/3.25798=N
> 
> 
> 
> >>
> 
> Please feedback what and where was the cause
> >
> >
> >
> > ___ Talk-be mailing
> > list Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> >
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


-- 
Dit bericht is ondertekend met OpenPGP.

signature.asc
Description: This is a digitally signed message part.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Glenn Plas]

-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 to the natural=water scheme but
> didn't remove the waterway=riverbank.

We should keep waterway=riverbank, and delete relation 2393380
altogether, it contains highway=paths and all sorts of stuff that
doesn't belong there.   There are seperated sections and also admin
boundaries that totally do not belong in a waterway.

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.

> 
>> Als ik straks ga meten hoelang de Leie is adhv. deze data gaat
>> dit niet juist zijn.
> 
> Obviously you should measure the type=waterway relation[2], not the
> type=multipolygon relation[1].

Sure, but what if I want to do it by name only, without tagging scheme
quirks.

There is no need for 2 relations, period.  "There can be... only one!"

Glenn




> 
> [1]
>> https://www.openstreetmap.org/relation/1201127
>> 
>> en
> 
> [2]
>> https://www.openstreetmap.org/relation/2393380
>> 
>> Er klopt ook nog steeds iets niet in die relaties/ways, als je
>> die links opendoet zie je het zo al.
>> 
>> Glenn
>> 
>> 
>> On 28-07-16 18:00, Ruben Maes wrote:
>>> Hi Frank
>>> 
>>> I've removed the area=no that was tagged on it. I think that
>>> was the cause, I hope it renders again soon.
>>> 
>>> On donderdag 28 juli 2016 17:54 Jakka wrote:
 Hi
 
 A note that the rendering of riverbank "Leie" between
 Kortrijk and Wervik is gone. In the past I added a lot of
 stuff there and it was good. Had corrected several overlap
 riverbanks en controlled begin to end but I do not know what
 to look after. The "Leie" is a natural border with France Has
 there been a mass update from there ?
 
 Some one with knowledge can check that?
 
 https://www.openstreetmap.org/note/646584#map=17/50.82877/3.25798=N



>>
 
Please feedback what and where was the cause
> 
> 
> 
> ___ Talk-be mailing
> list Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXmlH9AAoJELTQZq3fHKRZhcoQAJKSBzPBUMtf20DG+woETyrc
KUodnGaEGNNPUECKXmjF7bQkGzterXVccmlt3RqF7ZQgEYJ1iCkeaRs1J3nwmjM6
aUNTptnWP152CF3Xq9N/nPnqgZDUgPCRNPf+MAOMTL3CDbSWJD3xZKiWk65KxRfU
8KNXvhZFI5JiPdjFJRfaU2mAHYCfdvMItY9s9n6xK5+jwsUtuiGzZXMEnjUY3AAZ
y0JYimYZ5Sj2t7WF+XTi9XqXMvskTm++aTBD1a2IA+P1iy1NuCqArSAsRw51CMOt
K/oFJ24VFeXhPyNQULRhmSIwsRFqztI4eey5EHMKihBS34fho965xlcO2DDfSK8p
7XFti9h8U35UVUnO1q264NWadppCM4XS8lr1vVl647S4LO8HRdxsmML5Z6XBytCh
0TlM+KHvCLfHOqqJ/runlBloQxjcLYyWBYlxUJTnAhXb57Ni3C7bP/LOEfeNsBMJ
W4ls3slxF6RFAiYtdOobG2BR3EPtIRYqrbT/xIrcuGf3y5dDkv807KmZvup65kew
CvBWmHOVHq67PV1r8bLypDO9ghSvwfxkrDCrDBsmD/wQzknQS+uXNogIN3B1rZJD
Z1O25xY8bFzblAmXbgXbmft7dmBy45iObbO+GoZXoyET6PLblTn92P3JX/ynuTBB
4veF0Ja6u15epAw2H32i
=+Ps+
-END PGP SIGNATURE-

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

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

[Ruben Maes]

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 meten hoelang de Leie is adhv. deze data gaat dit
> niet juist zijn.

Obviously you should measure the type=waterway relation[2], not the 
type=multipolygon relation[1].

[1]
> https://www.openstreetmap.org/relation/1201127
> 
> en 

[2]
> https://www.openstreetmap.org/relation/2393380
> 
> Er klopt ook nog steeds iets niet in die relaties/ways, als je die
> links opendoet zie je het zo al.
> 
> Glenn
> 
> 
> On 28-07-16 18:00, Ruben Maes wrote:
> > Hi Frank
> >
> > I've removed the area=no that was tagged on it. I think that was
> > the cause, I hope it renders again soon.
> >
> > On donderdag 28 juli 2016 17:54 Jakka wrote:
> >> Hi
> >>
> >> A note that the rendering of riverbank "Leie" between Kortrijk
> >> and Wervik is gone. In the past I added a lot of stuff there and
> >> it was good. Had corrected several overlap riverbanks en
> >> controlled begin to end but I do not know what to look after. The
> >> "Leie" is a natural border with France Has there been a mass
> >> update from there ?
> >>
> >> Some one with knowledge can check that?
> >>
> >> https://www.openstreetmap.org/note/646584#map=17/50.82877/3.25798=N
> >>
> >>
> >>
> Please feedback what and where was the cause

-- 
Dit bericht is ondertekend met OpenPGP.

signature.asc
Description: This is a digitally signed message part.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Glenn Plas]

-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

en

https://www.openstreetmap.org/relation/2393380

Er klopt ook nog steeds iets niet in die relaties/ways, als je die
links opendoet zie je het zo al.

Glenn


On 28-07-16 18:00, Ruben Maes wrote:
> Hi Frank
> 
> I've removed the area=no that was tagged on it. I think that was
> the cause, I hope it renders again soon.
> 
> On donderdag 28 juli 2016 17:54 Jakka wrote:
>> Hi
>> 
>> A note that the rendering of riverbank "Leie" between Kortrijk
>> and Wervik is gone. In the past I added a lot of stuff there and
>> it was good. Had corrected several overlap riverbanks en
>> controlled begin to end but I do not know what to look after. The
>> "Leie" is a natural border with France Has there been a mass
>> update from there ?
>> 
>> Some one with knowledge can check that?
>> 
>> https://www.openstreetmap.org/note/646584#map=17/50.82877/3.25798=N
>>
>>
>> 
Please feedback what and where was the cause
>> 
>> Thx
> 
> 
> 
> ___ Talk-be mailing
> list Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXmkIqAAoJELTQZq3fHKRZVNYQAJdIUFu4dtmJH8+ZZLJ4SDg3
eHKE/l80O/K8imYA39vCTQ9QGt+GEllt7Nf65hY+/QDNRU2TAI1CEeYdF7vfn7rZ
X3dS8M9GiW9CbR8d75NpURUYsJY68d0Zrq1MX9w5JJi8xi41BGOvfIunMJYJdsWZ
DpEzT8uq0BRvRS3hH/RDn0jyGdQGKGNd0RpiWjyvZrE/WfFo+t1m7J0Vj1/MlvU3
29jhSTlfrRJFMDNg76dprrWdcsF1igjcFS+P+WrFdzntMlH0Ex1Zt0kskyYkC5wK
hvlUb1rcG4MqWmyVUyQ7pZsD/QHYlzv7QaXVmtBenQSU6bJ8Ch5KqJZ/tkp/AIdF
K9N2/yivEvnwE5u+GWdTnRE8fPFuj34JqPZjVtvOxac9TqyX/xqAO/98t3FSi3QE
1L7/G8ETpNeQKzmQBrP0ix0uO1DIDKuynt5vo2u2kev/6Ko2ASXmEBIKonrLwAUq
/ST0XuLb05x5f40kh28rqn7u2KLN5ovVahitadS00+8wm8/wBNQeoMThO9rJlpZ2
Kbp3qB9RXXZx4msVELZgX2EuR4dbtwuG7qELBixferiyQYtHJ0JU7thctuXOCB/X
/ALgn6UWM+7oyfNpZoEzZPvJVBK6HUbDiSNV5L9YfOL4PJLAvfNnpKjlHYyAyfC3
xGNgAGO1yQUSo60bx07u
=gZ3Y
-END PGP SIGNATURE-

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

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

[Ruben Maes]

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 28-07-16 18:00, Ruben Maes wrote:
> > Hi Frank
> >
> > I've removed the area=no that was tagged on it. I think that was
> > the cause, I hope it renders again soon.
> >
> > On donderdag 28 juli 2016 17:54 Jakka wrote:
> >> Hi
> >>
> >> A note that the rendering of riverbank "Leie" between Kortrijk
> >> and Wervik is gone. In the past I added a lot of stuff there and
> >> it was good. Had corrected several overlap riverbanks en
> >> controlled begin to end but I do not know what to look after. The
> >> "Leie" is a natural border with France Has there been a mass
> >> update from there ?
> >>
> >> Some one with knowledge can check that?
> >>
> >> https://www.openstreetmap.org/note/646584#map=17/50.82877/3.25798=N
> >>
> >>
> >>
> Please feedback what and where was the cause
> >>
> >> Thx
> >
> >
> >
> > ___ Talk-be mailing
> > list Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> >
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


-- 
Dit bericht is ondertekend met OpenPGP.

signature.asc
Description: This is a digitally signed message part.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] rendering

[Gerard Vanderveken]

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 om je positie te SMS'en naar vrienden en eventueel 
nooddiensten.


Met vriendelijke groeten,
Gerard

André Pirard wrote:


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 een redelijk gedetailleerde kaart te 
hebben om af te printen.


Ik ga namelijk de dodentocht doen, en mijn volgers zouden graag weten 
hoe de wandeling loopt. En internet access is niet mogelijk, vandaar 
de noodzaak om alles af te printen op papier.


alvast bedankt,

Bart


Salut Bart et tous,

GPSVisualizer.com  doit faire ce que tu 
veux.
Mais beaucoup diront qu'avant d'imprimer il faut penser à 
l'environnement !!!
Après chargement du fichier GPX sur un smartphone, le programme OSMand 
sera non seulement capable de montrer la piste GPX sur fond OSM mais 
aussi de la suivre en mode GPS, et ce sans Internet et sans papier.
Il faut vivre avec son temps et il y a de quoi amuser les promeneurs 
en ayant en poche un smartphone qui dit "tournez à gauche" ou bien 
"vous dépassez la vitesse limitée".  Dans un magasin, j'aime lui faire 
dire "Faites demi-tour dès que possible".


Cordialement,

André.




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

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

Re: [OSM-talk-be] rendering

[André Pirard]

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 maak ik zelf doorgaans
> gewoon screenshots.
Ou bien modifier ma carte que je montre de temps en temps
.
La ligne verte est une des piste GPX.
Recopier le fichier source HTML et changer les données. 

"Circuit de luges" ==> "Dodentocht"



> // create GPX traces var Hornay_Louveigné = new newGPX ("vélo
> Hornay-Louveigné", "gpx/Hornay-Louveigné.gpx"); var
> Princesse_Clémentine = new newGPX ("hike Princesse Clémentine",
> "gpx/Princesse_Clémentine.gpx"); var hike_8339 = new newGPX ("hike
> Co90 Sentier géologique", "gpx/8339_Co90_Sentier_géologique.gpx"); var
> Ru_de_Chawion_UCP = new newGPX ("Ru de Chawion UCP",
> "gpx/Ru_de_Chawion_UCP.gpx"); var luges = new newGPX ("Circuit de
> luges", "gpx/luges.gpx"); var work = new newGPX ("work",
> "gpx/work.gpx"); ... // Add a Layer for a GPX Track //
> OpenLayers.Format.GPX({extractRoutes: false, extractAttributes: false,
> extractWaypoints: false, extractTracks: false}) function newGPX(name,
> URL) { var GPX = new OpenLayers.Layer.Vector(name, { strategies: [new
> OpenLayers.Strategy.Fixed()], protocol: new OpenLayers.Protocol.HTTP({
> url: URL, format: new OpenLayers.Format.GPX() }), style: {strokeColor:
> "green", strokeWidth: 5, strokeOpacity: 0.5}, projection: new
> OpenLayers.Projection("EPSG:4326") }); map.addLayer(GPX); }

>
> Op 18 juli 2016 21:09 schreef Marc Gemis  >:
>
> 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
> > www.legendstracking.com/index.php/dodentocht/
>  zij bieden
> tracking aan
> > voor 20 euro. En dan ziet je familie je op de kaart, constant, niet
> > alleen aan de checkpoints.
> >
> > 2016-07-18 20:10 GMT+02:00 Bart Vanherck  >:
> >> 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 graag
> weten hoe de
> >> wandeling loopt. En internet access is niet mogelijk, vandaar
> de noodzaak om
> >> alles af te printen op papier.
> >>
> >> alvast bedankt,
> >>
> >> Bart
> >>
> >> ___
> >> Talk-be mailing list
> >> Talk-be@openstreetmap.org 
> >> https://lists.openstreetmap.org/listinfo/talk-be
> >>
> >
> >
> >
> > --
> > wannes
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
>
>
> -- 
> Joost @
> Openstreetmap
>  | Twitter
>  | LinkedIn
>  | Meetup
> 
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] rendering

[Marc Gemis]

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
> www.legendstracking.com/index.php/dodentocht/ zij bieden tracking aan
> voor 20 euro. En dan ziet je familie je op de kaart, constant, niet
> alleen aan de checkpoints.
>
> 2016-07-18 20:10 GMT+02:00 Bart Vanherck :
>> 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 graag weten hoe de
>> wandeling loopt. En internet access is niet mogelijk, vandaar de noodzaak om
>> alles af te printen op papier.
>>
>> alvast bedankt,
>>
>> Bart
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
>
>
> --
> wannes
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] rendering

[André Pirard]

  
  
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 een redelijk
  gedetailleerde kaart te hebben om af te printen.


Ik ga namelijk de dodentocht doen, en mijn volgers zouden
  graag weten hoe de wandeling loopt. En internet access is niet
  mogelijk, vandaar de noodzaak om alles af te printen op
  papier.


alvast bedankt,


Bart

  

Salut Bart et tous,

GPSVisualizer.com doit
faire ce que tu veux.
Mais beaucoup diront qu'avant d'imprimer il faut penser à
l'environnement !!!
Après chargement du fichier GPX sur un smartphone, le programme
OSMand sera non seulement capable de montrer la piste GPX sur fond
OSM mais aussi de la suivre en mode GPS, et ce sans Internet et sans
papier.
Il faut vivre avec son temps et il y a de quoi amuser les promeneurs
en ayant en poche un smartphone qui dit "tournez à gauche" ou bien
"vous dépassez la vitesse limitée".  Dans un magasin, j'aime lui
faire dire "Faites demi-tour dès que possible".

Cordialement,



  

  André.

  


  


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

[OSM-talk-be] rendering

[Bart Vanherck]

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 graag weten hoe
de wandeling loopt. En internet access is niet mogelijk, vandaar de
noodzaak om alles af te printen op papier.

alvast bedankt,

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

Re: [OSM-talk-be] rendering

[Sander Deryckere]

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" :

> 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 graag weten hoe
> de wandeling loopt. En internet access is niet mogelijk, vandaar de
> noodzaak om alles af te printen op papier.
>
> alvast bedankt,
>
> Bart
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Bryce Nesbitt]

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 open, in practice not much people are active there, it is
 rather detached from other parts of OSM and is rather conservative
 socially).


I see it as a relatively unhappy situation as well.  The osm-carto
maintainers spent a lot of time fending off requests and demands from
outsiders: it looks like a castle with barbarians at the gate.  I think a
new style, as open as the tagging scheme and database, is a way out both
for osm-carto's maintainers and for meeting the wider community needs.

--

Separately there's tension over the clutter of the map.  This really
should be broken down:

* Line styles and fills
* points of interest
* urban vs. rural areas.

New line styles and fills present a visual burden to understanding the
map.  Too many dashes dots and subtle color variations and everything looks
like mush.

New POI's, particularly obscure ones, impact few people because they are
usually not visible.  These often come with text labels that
help clarify the meaning of any symbol.  There really should be little
barrier to rendering more POI types.

Many issues are density dependent.  In a rural area showing everything is
generally just fine and desired.  For urban areas overload sets in by the
time the fire hydrants, manhole covers, electric lines, bike racks,  baby
hatches and crosswalks are all rendered. There's a lot of interesting work
to be done in the area of density specific rendering: rendering that's
sensitive to the scale density and land use type.


---
The map is also largely delivered in electronic form.  There's a lot of
potential for delivering dynamic legends and click for more information,
resolving many issues of potential viewer confusion.  The flat static map
need not communicate everything.
___
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]

[Daniel Koć]

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: [OSM-talk] Standard rendering totally fuzzy for countries boundaries

[Severin Menard]

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 UI is
improving more and more, would be great if the standard map becomes fully
understandable.

Sincerely,

Severin

On Thu, Feb 26, 2015 at 12:57 PM, moltonel 3x Combo molto...@gmail.com
wrote:

 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
  countries from each other. Eg in Westerm Africa from zoom 4, then zoom in
  on Senegal and Gambia down to zoom 9:
  http://www.openstreetmap.org/#map=4/15.88/-6.37
  I suggest to use the great improvements made on the osmfr rendering
  
 http://layers.openstreetmap.fr/?zoom=5lat=15.73535lon=-7.30745layers=BFF
 .

 There's already quite a lot of discussion on github on this subect:


 https://github.com/gravitystorm/openstreetmap-carto/issues?q=is%3Aissue+is%3Aopen+boundaries

 https://github.com/gravitystorm/openstreetmap-carto/issues?q=is%3Aissue+is%3Aopen+admin

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

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

[moltonel 3x Combo]

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
 countries from each other. Eg in Westerm Africa from zoom 4, then zoom in
 on Senegal and Gambia down to zoom 9:
 http://www.openstreetmap.org/#map=4/15.88/-6.37
 I suggest to use the great improvements made on the osmfr rendering
 http://layers.openstreetmap.fr/?zoom=5lat=15.73535lon=-7.30745layers=BFF.

There's already quite a lot of discussion on github on this subect:

https://github.com/gravitystorm/openstreetmap-carto/issues?q=is%3Aissue+is%3Aopen+boundaries
https://github.com/gravitystorm/openstreetmap-carto/issues?q=is%3Aissue+is%3Aopen+admin

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

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

[Matthijs Melissen]

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 the
 countries from each other. Eg in Westerm Africa from zoom 4, then zoom in on
 Senegal and Gambia down to zoom 9:
 http://www.openstreetmap.org/#map=4/15.88/-6.37
 I suggest to use the great improvements made on the osmfr rendering.


This is a known problem, see the following issue:

https://github.com/gravitystorm/openstreetmap-carto/issues/907

-- Matthijs

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

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

[Severin Menard]

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 in
on Senegal and Gambia down to zoom 9:
http://www.openstreetmap.org/#map=4/15.88/-6.37
I suggest to use the great improvements made on the osmfr rendering
http://layers.openstreetmap.fr/?zoom=5lat=15.73535lon=-7.30745layers=BFF.


Sincerely,

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

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

[Matthijs Melissen]

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 too). However,
there are still 333 other open issues, and the people in charge are
volunteers with a limited amount of time. If you would like to speed
things up, you're more than welcome to join us and write a pull
request on Github.

-- Matthijs

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

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

[althio]

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. This put people on the wrong track when preparing there citty trips.

 Or must I add a thith key/value??

 thx


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

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

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

[Sander Deryckere]

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 althio.fo...@gmail.com:

 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. This put people on the wrong track when preparing there citty
 trips.
 
  Or must I add a thith key/value??
 
  thx
 
 
  ___
  Talk-be mailing list
  Talk-be@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-be

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

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

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

[Jakka]

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 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
althio.fo...@gmail.com
mailto:althio.fo...@gmail.com:

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
mailto:vdmfrank...@gmail.com wrote:
  Is it possible that the rendering of a public parking or private
are the
  same. This put people on the wrong track when preparing there
citty trips.
 
  Or must I add a thith key/value??
 
  thx
 
 
  ___
  Talk-be mailing list
  Talk-be@openstreetmap.org
mailto:Talk-be@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-be

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




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





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

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

[Matthijs Melissen]

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 2014 22:23, 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:
 https://github.com/gravitystorm/openstreetmap-carto/issues/682

 We would welcome any feedback from the community on this decision. To keep
 the discussion centralized, we would prefer replies on Github rather than on
 the mailing list.

 -- Matthijs

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

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

[Martin Koppenhoefer]

 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...
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[martyn]

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 (PROWs), and extend access in areas with fewer 
PROWs.  They are not mapped on Ordnance Survey maps, probably due to 
their potential non-permanent status.  So having them surveyed and 
mapped in OSM is a useful  addition to PROW data, as information about 
them is not easy to find.


So please continue to render them if they are tagged as described in:
http://wiki.openstreetmap.org/wiki/UK_access_provisions

regards, Martyn

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

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

[Russ Nelson]

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 permission. access=private
means that you have to ask. access=no means that even if you ask, the
answer is no.

And indeed, Key:access documentation starts off with Access values
are used to describe the legal access, so I'm not completely off my
rocker.

-- 
--my blog is athttp://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-600-8815
Potsdam, NY 13676-3213  | Sheepdog   

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

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

[Russ Nelson]

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 athttp://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-600-8815
Potsdam, NY 13676-3213  | Sheepdog   

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

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

[Theodin]

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 map, as I know for certain that 
the large majority of
the main maps users uses it for car-related activity.
For other things, there are good specialised maps available.

Just my 2 cts.

Am 01.07.2014 01:15, schrieb Andy Street:
 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:
 https://github.com/gravitystorm/openstreetmap-carto/issues/682
 We would welcome any feedback from the community on this decision.
 I'd go one step further and advocate dropping all access=* rendering
 from the map. As access rights frequently vary depending on the mode of
 transport used it really only makes sense to show such information on
 specialist maps that cater for a particular class of user.

 To keep the discussion centralized, we would prefer replies on
 Github rather than on the mailing list.
 Sorry, I don't have a GitHub account.



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

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

[Janko Mihelić]

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 it was meant primarily for pedestrians (footway, path, pedestrian, maybe
even track) then render access for foot.

And if we want to go wild, maybe in zoom 19 render a little sign with a
crossed over pedestrian on service roads if pedestrians aren't allowed, or
something like that.

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

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

[Simon Poole]

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 05:33:49 MESZ, Marc Gemis marc.ge...@gmail.com wrote:
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 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.


 What would be useful would be some comments from the authors of these
 changes about what they think the standard map is actually _for_.
 Previously the story was that it was for mappers, but that seems to
be no
 longer the case.

 I've seen very little written justification for this series of
changes.
 The nearest on the previous change (
 https://github.com/gravitystorm/openstreetmap-carto/pull/542) was
but
 I've seen a few abandoned railway lines being rendered diagonally
across
 well mapped housing estates, and it looks terrible. - which is no
 justification at all; you could use a similar argument in favour of
not
 rendering natural=beach because people use it on golf courses.

 That's not to say that you _couldn't_ make an argument in favour of
the
 standard style becoming an Open Mapquest Lite - for map consumers
 rather than for map makers - but something needs to replace it, so
that new
 mappers can see the results of their efforts.  Or maybe mappers are
no
 longer such a rare resource that we don't need to encourage them any
more?

 Cheers,

 Andy



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






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

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[SomeoneElse]

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 
doesn't appear to be on the pull request.  What we have instead is 
Given that most uses, particularly of access=destination are actually 
wrong (excludes access far all, including pedestrians for example).  
What it'd be useful to have instead would be:


1) some examples of where access=destination is wrong (i.e. there really 
is more than destination access for specific modes and that isn't 
tagged) to help understand what the problem is perceived to be.


2) either a measurement of how widespread the problem is, or a 
description of how to measure how widespread the problem is.


Currently we don't have either of those - and without that there simply 
isn't the evidence to back up the proposed change.  That doesn't mean 
that it can't / won't be found (hence playing devil's advocate) just 
that we don't know yet.


Sometimes things that are obvious aren't actually true when you look 
at the data (new iD users making more errors than new users of other 
editors being an example of that, at least at the data that I looked at 
from England and Wales).


Cheers,

Andy


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

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

[Pieren]

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 (access=no or
access=private) and conditional access, whatever it is (destination,
permissive, forestry, type of vehicle, etc). In this way, it is usable
for the average reader and we still render all highways, thanks to the
contributors.
It's unrealistic to think that we can render and read on a map all
types of access conditions and combinations. It's like all surfaces
values. If someone needs the details, then keep that on specific
applications.

Pieren

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

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

[Simon Poole]

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 non-motorized modes of transportation access will
legally always be possible here, except in the case of access=private
(which should have been tagged instead if that is really the case).


Am 01.07.2014 11:18, schrieb SomeoneElse:
 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
 doesn't appear to be on the pull request.  What we have instead is
 Given that most uses, particularly of access=destination are actually
 wrong (excludes access far all, including pedestrians for example). 
 What it'd be useful to have instead would be:
 
 1) some examples of where access=destination is wrong (i.e. there really
 is more than destination access for specific modes and that isn't
 tagged) to help understand what the problem is perceived to be.
 
 2) either a measurement of how widespread the problem is, or a
 description of how to measure how widespread the problem is.
 
 Currently we don't have either of those - and without that there simply
 isn't the evidence to back up the proposed change.  That doesn't mean
 that it can't / won't be found (hence playing devil's advocate) just
 that we don't know yet.
 
 Sometimes things that are obvious aren't actually true when you look
 at the data (new iD users making more errors than new users of other
 editors being an example of that, at least at the data that I looked at
 from England and Wales).
 
 Cheers,
 
 Andy
 



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

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

[Martin Koppenhoefer]

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 it is (destination,
 permissive, forestry, type of vehicle, etc).



I believe that this is not possible to do consistently with current actual
tagging (if the public isn't just cars) (and available tags in rendering
db): we don't have needed subtags available in the db (like vehicle,
motor_vehicle, motorcycle), albeit a plethora of relevant tags does indeed
get imported: foot, bicycle, horse, motorcar, access (based on this style
sheet, not sure if it is the actual one:
https://github.com/openstreetmap/osm2pgsql/blob/master/default.style ). And
there are still many instances of access=no, bicycle=yes, foot=yes, etc.
where a motor_vehicle=no/private/destination would be more appropriate.

As a sidenote, I won't see permissive as conditional access, as this
should make no difference to the user compared to yes for practical
reasons.

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

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

[Arlindo Pereira]

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 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 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
on opensteetmap.org. See here for the discussion:
https://github.com/gravitystorm/openstreetmap-carto/issues/682

We would welcome any feedback from the community on this decision. To keep
the discussion centralized, we would prefer replies on Github rather than
on the mailing list.

-- Matthijs

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

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

[Nelson A. de Oliveira]

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 verde.

É uma boa mesmo.
Também seria bom se as pessoas não utilizassem access=permissive como
sinônimo de access=yes.

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

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

[Aun Johnsen]

Talvez deve documentar melhor os significativos dos valores access=*? 

Aun Johnsen
Sent from my iPhone

 On 1. juli 2014, at 14:09, 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 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 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 
 on opensteetmap.org. See here for the discussion: 
 https://github.com/gravitystorm/openstreetmap-carto/issues/682
 
 We would welcome any feedback from the community on this decision. To keep 
 the discussion centralized, we would prefer replies on Github rather than on 
 the mailing list.
 
 -- Matthijs
 
 ___
 talk mailing list
 t...@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk
 
 
 ___
 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-br] Fwd: [OSM-talk] Drop rendering of permissive access?

[Márcio Aguiar Ribeiro]

Aproveitando as dúvidas em relação ao access, eu tenho colocado o access de
ruas em condomínios fechados como access=private. Inclusive coloco um
barrier=gate na entrada. Infelizmente, acredito que isso acaba impedindo o
roteamento nessas ruas, o que seria interessante em condomínios grandes.

Qual é a orientação nesse caso?



Marcio Aguiar Ribeiro


On Tue, Jul 1, 2014 at 2:42 PM, Aun Johnsen li...@gimnechiske.org wrote:

 Talvez deve documentar melhor os significativos dos valores access=*?

 Aun Johnsen
 Sent from my iPhone

 On 1. juli 2014, at 14:09, 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 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 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
 on opensteetmap.org. See here for the discussion:
 https://github.com/gravitystorm/openstreetmap-carto/issues/682

 We would welcome any feedback from the community on this decision. To keep
 the discussion centralized, we would prefer replies on Github rather than
 on the mailing list.

 -- Matthijs

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


 ___
 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

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

[Roger C. Soares]

  
  
Eu tenho usado access=destination. Veja
  a thread:
  
https://lists.openstreetmap.org/pipermail/talk-br/2014-February/005476.html
  
  Atenciosamente,
  Roger.
  
  --
  Em 01-07-2014 14:44, Mrcio Aguiar Ribeiro escreveu:


  Aproveitando as dvidas em relao ao access, eu
tenho colocado o access de ruas em condomnios fechados como
access=private. Inclusive coloco um barrier=gate na entrada.
Infelizmente, acredito que isso acaba impedindo o roteamento
nessas ruas, o que seria interessante em condomnios grandes.

  

Qual  a orientao nesse caso?




  
  
Marcio Aguiar Ribeiro


On Tue, Jul 1, 2014 at 2:42 PM, Aun
  Johnsen li...@gimnechiske.org
  wrote:
  

  Talvez deve documentar melhor os significativos dos
valores access=*?

Aun Johnsen
Sent from my iPhone
  
  

  
On 1. juli 2014, at 14:09, Arlindo Pereira openstreet...@arlindopereira.com
wrote:

  
  

  
Discusso interessante no GitHub sobre se o
openstreetmap-carto (estilo padro de
renderizao no site 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 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 on opensteetmap.org.
  See here for the discussion: https://github.com/gravitystorm/openstreetmap-carto/issues/682
  

We would welcome any feedback from
  the community on this decision. To
  keep the discussion centralized, we
  would prefer replies on Github rather
  than on the mailing list.


  
  -- Matthijs


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

  
  

  

  

  
  

  ___
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

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

[Márcio Aguiar Ribeiro]

Excelente essa thread. Obrigado.

Marcio Aguiar Ribeiro


2014-07-01 16:06 GMT-03:00 Roger C. Soares rogersoa...@gmail.com:

  Eu tenho usado access=destination. Veja a thread:

 https://lists.openstreetmap.org/pipermail/talk-br/2014-February/005476.html

 Atenciosamente,
 Roger.

 --
 Em 01-07-2014 14:44, Márcio Aguiar Ribeiro escreveu:

 Aproveitando as dúvidas em relação ao access, eu tenho colocado o access
 de ruas em condomínios fechados como access=private. Inclusive coloco um
 barrier=gate na entrada. Infelizmente, acredito que isso acaba impedindo o
 roteamento nessas ruas, o que seria interessante em condomínios grandes.

  Qual é a orientação nesse caso?



 Marcio Aguiar Ribeiro


 On Tue, Jul 1, 2014 at 2:42 PM, Aun Johnsen li...@gimnechiske.org wrote:

  Talvez deve documentar melhor os significativos dos valores access=*?

 Aun Johnsen
 Sent from my iPhone

 On 1. juli 2014, at 14:09, 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 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 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 on opensteetmap.org. See here for the
 discussion:
 https://github.com/gravitystorm/openstreetmap-carto/issues/682

  We would welcome any feedback from the community on this decision. To
 keep the discussion centralized, we would prefer replies on Github rather
 than on the mailing list.

  -- Matthijs

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


 ___
 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 
 listTalk-br@openstreetmap.orghttps://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

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

[Paulo Carvalho]

Acho uma má ideia e além disso eles deveriam pensar nos muitos elementos de
mapa que hoje não são desenhados ao invés de parar de dar suporte a algo.
 Meu voto foi não.


Em 1 de julho de 2014 17:36, Márcio Aguiar Ribeiro aguiar.mar...@gmail.com
escreveu:

 Excelente essa thread. Obrigado.

 Marcio Aguiar Ribeiro


 2014-07-01 16:06 GMT-03:00 Roger C. Soares rogersoa...@gmail.com:

  Eu tenho usado access=destination. Veja a thread:


 https://lists.openstreetmap.org/pipermail/talk-br/2014-February/005476.html

 Atenciosamente,
 Roger.

 --
 Em 01-07-2014 14:44, Márcio Aguiar Ribeiro escreveu:

 Aproveitando as dúvidas em relação ao access, eu tenho colocado o access
 de ruas em condomínios fechados como access=private. Inclusive coloco um
 barrier=gate na entrada. Infelizmente, acredito que isso acaba impedindo o
 roteamento nessas ruas, o que seria interessante em condomínios grandes.

  Qual é a orientação nesse caso?



 Marcio Aguiar Ribeiro


 On Tue, Jul 1, 2014 at 2:42 PM, Aun Johnsen li...@gimnechiske.org
 wrote:

  Talvez deve documentar melhor os significativos dos valores access=*?

 Aun Johnsen
 Sent from my iPhone

 On 1. juli 2014, at 14:09, 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 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 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 on opensteetmap.org. See here for the
 discussion:
 https://github.com/gravitystorm/openstreetmap-carto/issues/682

  We would welcome any feedback from the community on this decision. To
 keep the discussion centralized, we would prefer replies on Github rather
 than on the mailing list.

  -- Matthijs

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


 ___
 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 
 listTalk-br@openstreetmap.orghttps://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

[OSM-talk] Drop rendering of permissive access?

[Matthijs Melissen]

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 the community on this decision. To keep
the discussion centralized, we would prefer replies on Github rather than
on the mailing list.

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

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

[Andy Street]

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:
 https://github.com/gravitystorm/openstreetmap-carto/issues/682
 We would welcome any feedback from the community on this decision.

I'd go one step further and advocate dropping all access=* rendering
from the map. As access rights frequently vary depending on the mode of
transport used it really only makes sense to show such information on
specialist maps that cater for a particular class of user.

 To keep the discussion centralized, we would prefer replies on
 Github rather than on the mailing list.

Sorry, I don't have a GitHub account.

-- 
Regards,

Andy Street

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

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

[SomeoneElse]

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 authors of these 
changes about what they think the standard map is actually _for_.  
Previously the story was that it was for mappers, but that seems to be 
no longer the case.


I've seen very little written justification for this series of changes.  
The nearest on the previous change 
(https://github.com/gravitystorm/openstreetmap-carto/pull/542) was but 
I've seen a few abandoned railway lines being rendered diagonally 
across well mapped housing estates, and it looks terrible. - which is 
no justification at all; you could use a similar argument in favour of 
not rendering natural=beach because people use it on golf courses.


That's not to say that you _couldn't_ make an argument in favour of the 
standard style becoming an Open Mapquest Lite - for map consumers 
rather than for map makers - but something needs to replace it, so that 
new mappers can see the results of their efforts.  Or maybe mappers are 
no longer such a rare resource that we don't need to encourage them any 
more?


Cheers,

Andy


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

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

[Marc Gemis]

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 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.


 What would be useful would be some comments from the authors of these
 changes about what they think the standard map is actually _for_.
 Previously the story was that it was for mappers, but that seems to be no
 longer the case.

 I've seen very little written justification for this series of changes.
 The nearest on the previous change (
 https://github.com/gravitystorm/openstreetmap-carto/pull/542) was but
 I've seen a few abandoned railway lines being rendered diagonally across
 well mapped housing estates, and it looks terrible. - which is no
 justification at all; you could use a similar argument in favour of not
 rendering natural=beach because people use it on golf courses.

 That's not to say that you _couldn't_ make an argument in favour of the
 standard style becoming an Open Mapquest Lite - for map consumers
 rather than for map makers - but something needs to replace it, so that new
 mappers can see the results of their efforts.  Or maybe mappers are no
 longer such a rare resource that we don't need to encourage them any more?

 Cheers,

 Andy



 ___
 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] Coastline rendering in Quebec

[Harald Kliems]

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:

* http://www.openstreetmap.org/?lat=45.6101lon=-73.4411zoom=13layers=M
This problem is comparatively recent. Current data appears to be
correct. Problem is visible on zoom=13

* http://www.openstreetmap.org/?lat=45.342lon=-74.24zoom=9layers=M
This one has been around for at least 6 months. Current data appears
to be correct. Problem is visible on zoom=9

We haven't been able to figure out who to contact about these issues.
Can anyone point us in the right direction?

Thanks,
 Harald.

-- 
Please use encrypted communication whenever possible!
Key-ID: 0x199DC50F

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

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

[Maarten Deen]

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. Apparently mapnik's renderering rules state that primary_link 
roads should be rendered below unclassified roads. I haven't inspected 
the rendering rules in detail (I'm also not familiar with them) but I 
have seen that tertiary_link roads are also rendered below unclassified 
roads. I expect that any *_link road is rendered below any other (or at 
least motorway - unclassified) road.


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 above the next lower road (so primary - primary_link 
- secondary).


[1] http://www.openstreetmap.org/?lat=51.352555lon=6.014996zoom=18
[2] http://www.openstreetmap.org/?lat=51.352419lon=6.010627zoom=18

Regards,
Maarten

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

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

[Richard Mann]

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 ought to be fixed, so this
information is offered on a tag-what-you-like basis, rather than a
render-as-I-do basis.

Richard

On Fri, May 4, 2012 at 1:09 PM, Maarten Deen md...@xs4all.nl wrote:

 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.
 Apparently mapnik's renderering rules state that primary_link roads should
 be rendered below unclassified roads. I haven't inspected the rendering
 rules in detail (I'm also not familiar with them) but I have seen that
 tertiary_link roads are also rendered below unclassified roads. I expect
 that any *_link road is rendered below any other (or at least motorway -
 unclassified) road.

 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 above the next lower road (so primary - primary_link - secondary).

 [1] 
 http://www.openstreetmap.org/?**lat=51.352555lon=6.014996**zoom=18http://www.openstreetmap.org/?lat=51.352555lon=6.014996zoom=18
 [2] 
 http://www.openstreetmap.org/?**lat=51.352419lon=6.010627**zoom=18http://www.openstreetmap.org/?lat=51.352419lon=6.010627zoom=18

 Regards,
 Maarten

 __**_
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk

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

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

[AJ Ashton]

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 above the next lower road (so primary - primary_link - secondary).

I would guess that, yes, this is the intention. The example you point
out is only minorly aesthetically displeasing. But if links were
rendered on top of unclassified roads, the situation of a link merging
into an unclassified (rather than passing through) would look much
worse. Example:

http://dl.dropbox.com/u/2398828/scrot/link_order.png

Granted, links don't feed into unclassifieds as often as they do
higher classifications of road, but it still happens a lot.

-- 
AJ Ashton

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

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

[Richard Mann]

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 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 above the next lower road (so primary - primary_link - secondary).

 I would guess that, yes, this is the intention. The example you point
 out is only minorly aesthetically displeasing. But if links were
 rendered on top of unclassified roads, the situation of a link merging
 into an unclassified (rather than passing through) would look much
 worse. Example:

 http://dl.dropbox.com/u/2398828/scrot/link_order.png

 Granted, links don't feed into unclassifieds as often as they do
 higher classifications of road, but it still happens a lot.

 --
 AJ Ashton

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

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

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

[Robert Tromp]

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 nothing wrong
(other than a few small mapping mishaps)
Furthermore, MapOSMatic, for example, creates perfectly good maps
(including edits I made to OSM after I first noticed the rendering
issue).

In the past weeks, neither regular nor forced re-renderings of the map
tiles have solved the problem.

Robert


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

When I look at [1] the status is: Tile is clean. Last rendered at Mon
Oct 10 12:56:45 2011

Forced rerendering seems to solve the problem. The area now looks fine
to me.

Frank


[1] http://a.tile.openstreetmap.org/16/58277/24359.png/status

Whatever the problem was with forced re-render, it seems fixed now.
As you've noticed yourself, a problem with scheduled re-renders or more 
accurate, the lack thereof, remains. The area is still showing alignment 
issues, grey tiles still start to show at zoom level 17, 18.
Hopefully that gets solved too, as I'm not eager to manually 
force-render a few hundred or even thousand map tiles.


Robert


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

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

[Robert Tromp]

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 example, creates perfectly good maps (including 
edits I made to OSM after I first noticed the rendering issue).

In the past weeks, neither regular nor forced re-renderings of the map tiles 
have solved the problem.

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

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

[Frank Steggink]

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 mapping mishaps)
Furthermore, MapOSMatic, for example, creates perfectly good maps 
(including edits I made to OSM after I first noticed the rendering issue).


In the past weeks, neither regular nor forced re-renderings of the map 
tiles have solved the problem.


Robert


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
When I look at [1] the status is: Tile is clean. Last rendered at Mon 
Oct 10 12:56:45 2011


Forced rerendering seems to solve the problem.  The area now looks fine to me.

Frank


[1] http://a.tile.openstreetmap.org/16/58277/24359.png/status

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

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

[pec...@gmail.com]

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
 http://en.wikipedia.org/wiki/United_Nations_General_Assembly_Resolut
 ion_194
 (see also http://en.wikipedia.org/wiki/Jerusalem#Political_status )

 (Note: I'm not taking sides in all this, but didn't realise there
 was such a political aspect to Jerusalem until doing a bit of
 research and thought the above made interesting reading for those
 not aware of the history involved. Disclaimer: I'm not saying
 Wikipedia is a reliable source).


Actually I have a question - why osm.org doesn't default to English
language of rendering entity names and if it's not available, to
closest one (in country official language, etc.) as it is now? This
would solve lot of such headaches. Jerusalem is Jerusalem in English
for both of nations.

Peteris.

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

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

[Maarten Deen]

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
resolutions such as
http://en.wikipedia.org/wiki/United_Nations_General_Assembly_Resolut
ion_194
(see also http://en.wikipedia.org/wiki/Jerusalem#Political_status )

(Note: I'm not taking sides in all this, but didn't realise there
was such a political aspect to Jerusalem until doing a bit of
research and thought the above made interesting reading for those
not aware of the history involved. Disclaimer: I'm not saying
Wikipedia is a reliable source).


Actually I have a question - why osm.org doesn't default to English
language of rendering entity names and if it's not available, to
closest one (in country official language, etc.) as it is now? This
would solve lot of such headaches. Jerusalem is Jerusalem in English
for both of nations.


Do you mean English language or Latin script? I think you mean Latin 
script, because Jerusalem in English language and Hebrew script is 
probably still not acceptable to the Palestinian side.


But rendering in Latin script opens the question what to do in China, 
Japan, Russia, Egypt and all other countries not using the Latin script. 
_I_ would really like to see all names rendered in Latin script, but 
that is just my western-centered viewpoint and will probably clash with 
the views of people in those countries not using the Latin script (and 
therefore not really an option).

Maybe some script overlays would be a nice addition to the main map.

Regards,
Maarten



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

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

[Anthony]

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 closed way implies that this closed way represents an area
 called Melbourne;Geelong;South-Central NSW Area;Central Victoria
 Area.

 I'm not sure boundary=* is appropriate either, as this is not a
 political or governmental or pseudo-governmental division, though
 maybe I'm just not aware of how broadly that tag is used.

 Cool. Well, since these areas aren't AFAIK used for anything except
 these kinds of maps: http://wiki.openstreetmap.org/wiki/Nearmap ,
 there's no particular need for them to have tags like name=* or
 boundary=*. I've changed this one.

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.

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

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

[Lester Caine]

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.


This is the real problem!
With more and more historic mapping material coming on line, and what seems like 
little support for the start_date/end_date tagging of physical objects that we 
have fairly accurate data on when they did make an appearance or when they were 
redeveloped, linking to other data sources where this information can be stored 
would at least allow it's integration?


And the creation of 'temporary' layers where material is being worked on but has 
not yet been fully integrated would also seem to be a way forward even for 
general mapping?


--
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//
Firebird - http://www.firebirdsql.org/index.php

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