On 29/10/2014, Richard Z. ricoz@gmail.com wrote:
On Tue, Oct 28, 2014 at 05:21:06PM +0100, moltonel 3x Combo wrote:
On 28/10/2014, Richard Z. ricoz@gmail.com wrote:
well even if the issues were nonexistent, mapping the area of a bay seems
to me like mapping an artificially introduced
On Tuesday 28 October 2014, Janko Mihelić wrote:
If you want to formulate a formal mathematical rule for where the
node for a bay is best placed: Place it so the variance of the
distance of the node to the bay's shores is minimized. Most
existing nodes comply with this rule remarkably
On Mon, Oct 27, 2014 at 04:28:53PM -0400, Eric Kidd wrote:
But the key point here is that none of these official sources represent
bays as polygons. GNIS uses a pointssomewhere in the bay. The nautical
charts print the name somewhere in the middle of the bay. Effectively, the
official data
2014-10-28 10:57 GMT+01:00 Richard Z. ricoz@gmail.com:
Also, I am reading the arguments about estimating bay area so I am curious
- when was the last time someone asked about bay area in square kilometers?
I think it makes only sense in the context of territorial waters, fishing
or
On Tue, Oct 28, 2014 at 11:18:43AM +0100, Martin Koppenhoefer wrote:
2014-10-28 10:57 GMT+01:00 Richard Z. ricoz@gmail.com:
Also, I am reading the arguments about estimating bay area so I am curious
- when was the last time someone asked about bay area in square kilometers?
I think it
On Tue, 28 Oct 2014, Christoph Hormann wrote:
On Tuesday 28 October 2014, Janko Mihelić wrote:
If you want to formulate a formal mathematical rule for where the
node for a bay is best placed: Place it so the variance of the
distance of the node to the bay's shores is minimized. Most
On 27/10/2014, Christoph Hormann chris_horm...@gmx.de wrote:
Since for label rendering you don't really need a polygon there is
little point in actually generating it in the first place. But i have
implemented and used techniques not unlike the algorithm described for
rendering bay and strait
On 28/10/2014, Richard Z. ricoz@gmail.com wrote:
On Tue, Oct 28, 2014 at 11:18:43AM +0100, Martin Koppenhoefer wrote:
2014-10-28 10:57 GMT+01:00 Richard Z. ricoz@gmail.com:
The assumption is that a large bay will typically be more important than a
smaller bay. For a good rendering
On Tuesday 28 October 2014, Ilpo Järvinen wrote:
But are all bays 'mostly surrounded by land' or do some bays also
have very wide entrypoints (in addition to two pockets to trigger
this peninsula case)? And yes, I know it can always be solved by
drawing area manually if the algorithm won't
On Tuesday 28 October 2014, moltonel 3x Combo wrote:
That's actually a very nice rendering. The channels in particular
seem to be oriented very naturally. But when I look at the underlying
osm data (nodes), it is much less clear how those features are
oriented. I feel like the rendering
On 26.10.2014 17:12, Mateusz Konieczny wrote:
Please, try mapping bays as areas - not as nodes.
but if you - for whatever reason ever - can't map it as area then it's
better to map it as node instead not mapping it at all...
Just an example: I did it some times ago with something (can't
On 26/10/2014, Christoph Hormann chris_horm...@gmx.de wrote:
I don't see what information is missing and cannot be easily determined
automatically with a properly placed node that is contained in an
area - except for the outer edge of course, which is usually
ill-defined though as you said
2014-10-26 17:12 GMT+01:00 Mateusz Konieczny matkoni...@gmail.com:
Please, try mapping bays as areas - not as nodes.
+1. Please do this also for place=country and other place objects that are
indeed describing polygons and not points.
___
Tagging
2014-10-26 19:00 GMT+01:00 Christoph Hormann chris_horm...@gmx.de:
Doable for sure but an awfully bad idea, mapping bays as areas would
mean two features for the same object (coastline polygon and bay area).
I don't see one object. There is a coastline (linear division between
land and sea,
2014-10-26 21:38 GMT+01:00 Christoph Hormann chris_horm...@gmx.de:
Specific arguments aside - i am not sure if you realize the consequences
it would have if subareas of oceans would generally be mapped as
polygons - large bays usually contain smaller bays and are parts of a
sea and there
I had a proposal about mapping peninsulas [1] and it involved adding
peninsula=* tags to coastlines. I think bays should be mapped the same way,
on coastline ways. The question is what tags we should use. Adding new ways
and gluing them to coastlines, when coastlines themselves make a bay is in
my
On Sun, 26 Oct 2014, Christoph Hormann wrote:
On Sunday 26 October 2014, Mateusz Konieczny wrote:
Furthermore the outer edge of a bay, i.e. the edge that is not
coastline is usually not well defined and would require an
arbitrary cutoff.
Yes, cutoff is unfortunately quite arbitrary.
On Mon, Oct 27, 2014 at 11:33 AM, Ilpo Järvinen ilpo.jarvi...@helsinki.fi
wrote:
Besides, we really need to deal with object that have fuzzy borders
already, e.g., some of the natural=wetland object come to my mind as an
example. I quickly browsed through the related pages and discussions, for
On Monday 27 October 2014, moltonel 3x Combo wrote:
If you think about it a bit and do not try to place the node where
you would place the label (which depends on the map projection
anyway) properly placing a node for a bay is usually quite simple.
The most difficult are long,
On Mon, 27 Oct 2014, Marc Gemis wrote:
On Mon, Oct 27, 2014 at 11:33 AM, Ilpo Järvinen ilpo.jarvi...@helsinki.fi
wrote:
Besides, we really need to deal with object that have fuzzy
borders
already, e.g., some of the natural=wetland object come to my
mind as an
On Mon, Oct 27, 2014 at 10:44:01AM +0100, moltonel 3x Combo wrote:
On 26/10/2014, Christoph Hormann chris_horm...@gmx.de wrote:
I don't see what information is missing and cannot be easily determined
automatically with a properly placed node that is contained in an
area - except for the
On Mon, Oct 27, 2014 at 12:33:48PM +0200, Ilpo Järvinen wrote:
On Sun, 26 Oct 2014, Christoph Hormann wrote:
On Sunday 26 October 2014, Mateusz Konieczny wrote:
Furthermore the outer edge of a bay, i.e. the edge that is not
coastline is usually not well defined and would require an
2014-10-27 12:16 GMT+01:00 Richard Z. ricoz@gmail.com:
Besides, we really need to deal with object that have fuzzy borders
already, e.g., some of the natural=wetland object come to my mind as an
example. I quickly browsed through the related pages and discussions, for
some strange
On 27/10/2014, Christoph Hormann chris_horm...@gmx.de wrote:
On Monday 27 October 2014, moltonel 3x Combo wrote:
I'm really curious what your method to figure out the bay area from
the node is, because even as a human I find that most bay nodes can
lead to many different interpretations.
On 27/10/2014, Richard Z. ricoz@gmail.com wrote:
On Mon, Oct 27, 2014 at 10:44:01AM +0100, moltonel 3x Combo wrote:
I'm really curious what your method to figure out the bay area from
the node is, because even as a human I find that most bay nodes can
lead to many different
On Monday 27 October 2014, moltonel 3x Combo wrote:
This extremely simple approach will probably result in reasonable
polygons for label placement in more than half the cases. You can
easily improve the algorithm of course to properly deal with
various special cases, in particular the
2014-10-27 16:24 GMT+01:00 Christoph Hormann chris_horm...@gmx.de:
No, that is not how OSM works. The mappers can choose a method to map
they deem appropriate - which in this case quite clearly is nodes (less
than 0.5 percent ways and relations according to taginfo).
the same holds true
On 27/10/2014, Christoph Hormann chris_horm...@gmx.de wrote:
On Monday 27 October 2014, moltonel 3x Combo wrote:
This extremely simple approach will probably result in reasonable
polygons for label placement in more than half the cases. You can
easily improve the algorithm of course to
2014-10-27 16:24 GMT+01:00 Christoph Hormann chris_horm...@gmx.de:
I can't help but notice that in the whole discussion here no argument
has been put formward indicating a practical advantage of bays mapped
as polygons other than the ease of rendering labels.
Reverse geocoding. A boat comes
On Monday 27 October 2014, Janko Mihelić wrote:
I can't help but notice that in the whole discussion here no
argument has been put formward indicating a practical advantage of
bays mapped as polygons other than the ease of rendering labels.
Reverse geocoding. A boat comes to a bay, captain
On Monday 27 October 2014, moltonel 3x Combo wrote:
Have you tried it?
On the contrary - due to its simplicity it is a very robust
algorithm, it will hardly ever generate something completely wrong
and fail gracefully in difficult cases. And as said it is strait
away to extend this
On 27/10/2014, Christoph Hormann chris_horm...@gmx.de wrote:
On Monday 27 October 2014, Janko Mihelić wrote:
Reverse geocoding. A boat comes to a bay, captain looks on a screen,
and it says You are in Guantanamo Bay.
But this is exactly what does not work with a hand mapped polygon either
2014-10-27 17:37 GMT+01:00 Christoph Hormann chris_horm...@gmx.de:
But this is exactly what does not work with a hand mapped polygon either
since the edge of the bay is not well defined.
it will work in most cases, and only give questionable information when you
are close to the fuzzy end
On Mon, 27 Oct 2014, Martin Koppenhoefer wrote:
2014-10-27 17:37 GMT+01:00 Christoph Hormann chris_horm...@gmx.de:
But this is exactly what does not work with a hand mapped
polygon either
since the edge of the bay is not well defined.
it will work in most cases,
When working near the coast of Maine in the US, I see lots of bays. In
most cases, the ultimate source data for the bay names seems to be various
government maps and databases: GNIS, ancient nautical charts, or whatever.
There's a high degree of agreement between sources: If an island has 4
On Monday 27 October 2014, Ilpo Järvinen wrote:
IMHO, the most controversial thing in this all is that the approach
Christoph is proposing would require us to not map natural=bay but
natural=bay_entry instead, and that is obviously exactly where the
fuzzy part is. That is, a mapper would be
Dana 27. 10. 2014. 21:30 osoba Eric Kidd emk.li...@randomhacks.net
napisala je:
The rendering onopenstreetmap.orgis pretty good: it just prints the bay
name at the marked point, and shows it across a reasonable range of scales.
There are some weird cases with nested bays, but those are weird on
Please, try mapping bays as areas - not as nodes.
It is really rare to see it done this way - but it is doable, see
http://overpass-turbo.eu/s/5CQ
Bay mapped as node is hard to process - for example: deciding whatever name
should be
rendered. It is completely impossible to retrieve information
On Sunday 26 October 2014, Mateusz Konieczny wrote:
Please, try mapping bays as areas - not as nodes.
It is really rare to see it done this way - but it is doable, see
http://overpass-turbo.eu/s/5CQ
Doable for sure but an awfully bad idea, mapping bays as areas would
mean two features for
Doable for sure but an awfully bad idea, mapping bays as areas would
mean two features for the same object (coastline polygon and bay area).
Coastline polygon and bay area is not the same object. Yes, part of border
is
shared - it is nothing wrong. Also it is possible to use for example
On Sunday 26 October 2014, Mateusz Konieczny wrote:
Furthermore the outer edge of a bay, i.e. the edge that is not
coastline is usually not well defined and would require an
arbitrary cutoff.
Yes, cutoff is unfortunately quite arbitrary. But node placement is
completely arbitrary - and
On Sun, Oct 26, 2014 at 05:12:20PM +0100, Mateusz Konieczny wrote:
Please, try mapping bays as areas - not as nodes.
It is really rare to see it done this way - but it is doable, see
http://overpass-turbo.eu/s/5CQ
not practical in most cases. Almost every bay is part of a larger bay
and so
On Fri, Apr 25, 2014 at 02:07:15PM +0100, Philip Barnes wrote:
On Thu, 2014-04-24 at 23:03 -0700, Bryce Nesbitt wrote:
How best should I tag informal swimming areas? These typically have
no lifeguard or facilities. An example deep-content site for these
types of holes is:
How best should I tag informal swimming areas? These typically have no
lifeguard or facilities. An example deep-content site for these types of
holes is:
http://www.iforgotthename.com/
In OSM is it best to create an area and tag
sport=swimming/name=/access=/fee=no?
On Thu, Apr 24, 2014 at 11:03:50PM -0700, Bryce Nesbitt wrote:
How best should I tag informal swimming areas? These typically have no
lifeguard or facilities. An example deep-content site for these types of
holes is:
http://www.iforgotthename.com/
In OSM is it best to create an area and
On Thu, 2014-04-24 at 23:03 -0700, Bryce Nesbitt wrote:
How best should I tag informal swimming areas? These typically have
no lifeguard or facilities. An example deep-content site for these
types of holes is:
http://www.iforgotthename.com/
In OSM is it best to create an area and tag
On the contrary, where there's water you can technically swim.
I'm not against mapping informal places, but they should be well known for such
activities.
On 25 avril 2014 15:07:15 UTC+02:00, Philip Barnes p...@trigpoint.me.uk wrote:
On Thu, 2014-04-24 at 23:03 -0700, Bryce Nesbitt wrote:
How
On 2014-04-25 08:03, Bryce Nesbitt
wrote :
How best should I tag informal swimming areas? These
typically have no lifeguard or facilities. An example
deep-content site for these types of holes is:
On Fri, Apr 25, 2014 at 2:03 AM, Bryce Nesbitt bry...@obviously.com wrote:
How best should I tag informal swimming areas? These typically have no
lifeguard or facilities. An example deep-content site for these types of
holes is:
http://www.iforgotthename.com/
In OSM is it best to create an
On Fri, Apr 25, 2014 at 6:07 AM, Philip Barnes p...@trigpoint.me.uk wrote:
Forgetting the tagging for a moment, is it not irresponsible to be
mapping and thus being seen as encouraging such activities?
Every year when there is hot weather there are warnings not to swim in
lakes and rivers,
I reread this thread today, and what gave away the joke is that there is
agreement. Most messages quote the previous one and comment Great!
Also
Merry Christmas,
Simone
2014-04-02 2:38 GMT+02:00 André Pirard a.pirard.pa...@gmail.com:
On 2014-04-01 19:08, Pierre Knobel wrote :
Hi all,
Hi all,
I'm new on this mailing list, but I spend a few months already on the
talk-fr list and I've been mapping for a while longer.
I just wanted to mention a new tag I created yesterday:
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcloud
I was quite surprised that there wasn't already a
On 1 April 2014 18:08, Pierre Knobel pierr...@gmail.com wrote:
I just wanted to mention a new tag I created yesterday:
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcloud
I think this is tag a very good idea. Clouds are very noticeable
features in the landscape. I just have some concerns
I am hoping this has something to do with it being April 1st
On Tue, Apr 1, 2014 at 11:14 AM, Matthijs Melissen i...@matthijsmelissen.nl
wrote:
On 1 April 2014 18:08, Pierre Knobel pierr...@gmail.com wrote:
I just wanted to mention a new tag I created yesterday:
On Tuesday 01 April 2014, Pierre Knobel wrote:
Hi all,
I'm new on this mailing list, but I spend a few months already on the
talk-fr list and I've been mapping for a while longer.
I just wanted to mention a new tag I created yesterday:
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcloud
2014-04-01 19:14 GMT+02:00 Matthijs Melissen i...@matthijsmelissen.nl:
On 1 April 2014 18:08, Pierre Knobel pierr...@gmail.com wrote:
I just wanted to mention a new tag I created yesterday:
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcloud
I think this is tag a very good idea. Clouds
I see the problem, it's tricky. Maybe we've hit the boundaries of what it
is possible to achieve with nodes, ways and relations. Maybe we should ask
the developers to add a new type of object that would be more suitable for
this situation. It would need to be diffuse, span over several layers and
Sounds about right, but add layer=* tags where appropriate. Clouds go above
the land, so we have to make sure they render above everything (except
certain bridges and buildings). Might as well add layer=5 to all of them
for good measure.
On Apr 1, 2014 12:16 PM, Matthijs Melissen
Pierre Knobel wrote on Tue, 1 Apr 2014 19:08:01 +0200:
I'm new on this mailing list, but I spend a few months already on the
talk-fr list and I've been mapping for a while longer.
I just wanted to mention a new tag I created yesterday:
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcloud
I
Rendering for natural=cloud has been added to the FR rendering:
http://tile.openstreetmap.fr/?zoom=15lat=48.63541lon=-1.51142layers=B000FFT
white = non rainy cloud
dark = rainy cloud
2014-04-01 19:25 GMT+02:00 Clay Smalley claysmal...@gmail.com:
Sounds about right, but add layer=*
On Tue, Apr 01, 2014 at 12:25:03PM -0500, Clay Smalley wrote:
Sounds about right, but add layer=* tags where appropriate. Clouds go above
the land, so we have to make sure they render above everything (except
certain bridges and buildings). Might as well add layer=5 to all of them
for good
On Wednesday 11 September 2013, Tod Fitch wrote:
There are some grasses there but small woody plants predominate in
that area. So that would indicate heath. But how does one note the
difference, significant to a hiker, that you can easily walk through
this area while the chaparral at lower
On Wed, September 11, 2013 10:17 am, Christoph Hormann wrote:
On Wednesday 11 September 2013, Tod Fitch wrote:
Drought winter in one area of interest:
http://kirnim.smugmug.com/2013Adventures-2/Mt-Pinos-Feb-2013/i-cJXHsL
S/0/M/P1110823-M.jpg
Summer in another area:
Tod Fitch t...@fitchdesign.com wrote:
On Tue, September 10, 2013 2:16 pm, John Eldredge wrote:
On 09/10/2013 04:06 PM, Dominik George wrote:
Why? If there is a difference, then there is a difference.
BTW, mind fix your From name, Mrs. or Mr. Gmail?
-nik
Gmail yve...@gmail.com
2013/9/11 Christoph Hormann chris_horm...@gmx.de
there is simply no way with the current OSM data
model to properly map deserts.
+1, generally we are not well prepared to map huge geographic areas or
ecosystems. I fear that also tundras fall into this kind of (at least
currently) unmappable
On Wednesday 11 September 2013, Tod Fitch wrote:
Drought winter in one area of interest:
http://kirnim.smugmug.com/2013Adventures-2/Mt-Pinos-Feb-2013/i-cJXHsL
S/0/M/P1110823-M.jpg
Summer in another area:
http://www.nordicbase.org/files/web_images/sawmill_mtn.jpg
The problem here is that
2013/9/11 Christoph Hormann chris_horm...@gmx.de
This already goes in direction of scrub - in fact the distinction
between scrub and heath is not well defined.
wikipedia says scrubs can have trees up to 8m while heath they limit to 2,
but actually they divide scrubs into 8 subtypes, two of
On Tuesday 10 September 2013, Tod Fitch wrote:
[...]
And the Wikipedia page regarding alpine tundra affirms it:
http://en.wikipedia.org/wiki/Alpine_tundra
But the closest looking tag I see at
http://wiki.openstreetmap.org/wiki/Key:natural seems to be
natural=fell
I had looked at that as
On Tue, September 10, 2013 2:16 pm, John Eldredge wrote:
On 09/10/2013 04:06 PM, Dominik George wrote:
Why? If there is a difference, then there is a difference.
BTW, mind fix your From name, Mrs. or Mr. Gmail?
-nik
Gmail yve...@gmail.com schrieb:
In a geo database, tundra alone
Why? If there is a difference, then there is a difference.
BTW, mind fix your From name, Mrs. or Mr. Gmail?
-nik
Gmail yve...@gmail.com schrieb:
In a geo database, tundra alone must be sufficient, don't you think ?
Tod Fitch t...@fitchdesign.com a écrit :
I'd like to start adding some
On Tue, September 10, 2013 2:37 pm, Christoph Hormann wrote:
[...]
The real problem about natural=tundra is that it is a very broad
classification. Essentially it starts at the treeline with often quite
lush grass or woody vegetation and ends with scattered lichens. In a
way natural=tundra
2010/8/28 Xan dxpubl...@telefonica.net:
Hi,
I made a new proposal of natural_protection tag (section new proposal of
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Key:natural_protection).
Can you comment it? I'm still a newbee so before making a definitive
proposed page, I want
Hi,
I made a new proposal of natural_protection tag (section new proposal of
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Key:natural_protection).
Can you comment it? I'm still a newbee so before making a definitive
proposed page, I want to know your opinion.
Thanks in advance,
On 24 August 2010 03:48, Erik G. Burrows e...@erikburrows.com wrote:
I think that if we map the park/city/etc boundary as a separate way than
the river/ridge/etc, we give ourselves greater flexibility over time:
In general this is the conclusion we've come to about Australian
boundaries, keep
On Tue, Aug 24, 2010 at 3:48 AM, Erik G. Burrows e...@erikburrows.com wrote:
3. Most renderers draw line features on top of polygon features making the
rendering nicer looking
In practice, having two independent ways actually renders worse,
because they tend to criss-cross each other
On Wed, Aug 25, 2010 at 10:00 AM, Steve Bennett stevag...@gmail.com wrote:
To pick a random example:
http://osm.org/go/uG2Mh6iR
Oops, sorry for spam, but nearby I spotted a convenient example of the
alternative approach: one way that serves as both administrative
boundary and river.
On 25 August 2010 10:03, Steve Bennett stevag...@gmail.com wrote:
On Wed, Aug 25, 2010 at 10:00 AM, Steve Bennett stevag...@gmail.com wrote:
To pick a random example:
http://osm.org/go/uG2Mh6iR
Oops, sorry for spam, but nearby I spotted a convenient example of the
alternative approach: one
Thanks Michael and Liz.
I've been thinking about this for a while, and putting off mapping many of
the streams/rivers in the Sierra Mountains because of this uncertainty.
It seems that there is no general consensus, so I would like to propose
what I think is the best trade-off:
I think that
I have several cases where a border polygon (national park, wilderness,
etc.) is defined based on a natural feature, such as a
stream/crestline/etc.
What is the preferred way to handle this dual-purpose way?
Splitting the border way, creating a relation of the border pieces, and
adding the
What is the preferred way to handle this dual-purpose way?
In some forms of rendering the boundary is rendered instead of the stream
and
the water feature disappears on the map.
The preferred Australian solution is to not reuse the same boundary but to
duplicate it. This allows all
I'd prefer relations. Duplicating the line to offset is borderline
micro-mapping; I don't think micro-mapping is practical in a lot of cases
right now.
On Tue, Aug 10, 2010 at 3:08 PM, Erik G. Burrows e...@erikburrows.comwrote:
I have several cases where a border polygon (national park,
101 - 181 of 181 matches
Mail list logo
