Re: [OSM-talk] New Coastline in Mapnik - Glasgow cIty center issue
On Wed, 2008-02-06 at 22:41 +, Jon Burgess wrote: > I have switch the Mapnik layer over to use the new coastline shapefiles > for zooms 10-18. These files are generated by extracting all the OSM > ways with natural=coastline. > > In most places these shapefiles are far better then what we had before. > A few places either have bad coastline data and may now appear to be > flooded. You can get an overview of the data from: > http://tile.openstreetmap.nl > > There was a brief period this evening where an error caused all tiles to > be flooded. This is fixed now and these tiles should have been > re-rendered. If you saw these bad tiles earlier you might need to > refresh your browser to get rid of them. > > I need to thank everyone that has worked diligently on importing and > fixing up the coastline data. A special mention should also go to > Martijn van Oosterhout (kleptog) for developing the tools that have been > essential to fix these coastlines and create the new shapefiles. Thanks to all for working on this! The River Clyde in Glasgow is almost perfect now. I say almost because there seems to be an issue between Bridge Street/A77 and the A74: http://www.openstreetmap.org/?lat=55.85324&lon=-4.25218&zoom=15&layers=B0FT I've just upgraded my system so i don't have JOSM running at the moment, it would be great if someone could take a look and fix this. Keith. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] New Coastline in Mapnik - Glasgow cIty center issue
- Original Message - From: "Keith Sharp" <[EMAIL PROTECTED]> To: Sent: Friday, February 08, 2008 8:52 AM Subject: Re: [OSM-talk] New Coastline in Mapnik - Glasgow cIty center issue > > On Wed, 2008-02-06 at 22:41 +, Jon Burgess wrote: >> I have switch the Mapnik layer over to use the new coastline shapefiles >> for zooms 10-18. These files are generated by extracting all the OSM >> ways with natural=coastline. >> >> In most places these shapefiles are far better then what we had before. >> A few places either have bad coastline data and may now appear to be >> flooded. You can get an overview of the data from: >> http://tile.openstreetmap.nl >> >> There was a brief period this evening where an error caused all tiles to >> be flooded. This is fixed now and these tiles should have been >> re-rendered. If you saw these bad tiles earlier you might need to >> refresh your browser to get rid of them. >> >> I need to thank everyone that has worked diligently on importing and >> fixing up the coastline data. A special mention should also go to >> Martijn van Oosterhout (kleptog) for developing the tools that have been >> essential to fix these coastlines and create the new shapefiles. > > Thanks to all for working on this! The River Clyde in Glasgow is almost > perfect now. I say almost because there seems to be an issue between > Bridge Street/A77 and the A74: > > http://www.openstreetmap.org/?lat=55.85324&lon=-4.25218&zoom=15&layers=B0FT > > I've just upgraded my system so i don't have JOSM running at the moment, > it would be great if someone could take a look and fix this. Fixed David > > Keith. > > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Large Rivers in general, mapnik rendering in Particular
The proposed tag waterway = river, http://wiki.openstreetmap.org/index.php/Proposed_features/Large_rivers , has been at proposal stage for over 18 months, which seems far too long for a tag which represents such an important feature. The main problem area seems to be that some people do not like the current proposal whereby a river is divided up in to separate closed areas. The reason being that the "segment" crossing the river to close the area marks a boundary which does not actually exist. Discussion on this could go on indefinitely, but it does really need a Mapnik "expert" to either (i) see if there is a way that Mapnik can render areas which are not closed (ie. comprised of two parallel ways), or (ii) if this is not , and will never be, possible then to state that fact , and we can then have a tag proposal which will render in both Mapnik and [EMAIL PROTECTED] The main issue in practice is we now have no standard way of tagging rivers, and people are relatively free to do what they like, with the result that large portions of the River Thames disappeared from the Mapnik layer recently http://www.informationfreeway.org/?lat=51.49&lon=0.41&zoom=11&layers=F0B0F David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular
On Feb 8, 2008 11:09 AM, Artem Pavlenko <[EMAIL PROTECTED]> wrote: > We can make osm2pgsql or coastline tools to create polygons, but why > not create them in the first place ? > Can someone enlighten me, please ? If I wanted to draw the rivers as light blue* with dark blue riverbanks, wouldn't storing them as polygons would make this hard? I don't think it would be easy to work out which sections of the polygons are where the river continues as opposed to being the riverbank. If we store the riverbanks, then we can pre-process to our hearts content using osm2pgsql and the like. That way I could have riverbanks as polylines and rivers as polygons and render them as I see fit. The pre-processing could work very similarly to the coastlines, using a left- or right-hand side rule and continuing the riverbank where one way joins onto the next to construct the polygons required. Cheers, Andy * As I think more and more about contours, and semi-transparent renderings and so on I realise that most area-fills will be translucent with edges on my maps, so we need to avoid abutting polygons if we aren't intending to represent an edge. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular
- Original Message - From: "David Earl" <[EMAIL PROTECTED]> To: "Artem Pavlenko" <[EMAIL PROTECTED]> Cc: "David Groom" <[EMAIL PROTECTED]>; Sent: Friday, February 08, 2008 11:27 AM Subject: Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular > You could do it as a relation. > > The river bank would be a set of ways (each of which shares its end nodes > with the ends of one of the others), and you could have a role for the one > or two ways which close the loop which says "this is structural, not > really part of the river bank". The renderer would have to assemble the > polygon from the constituent ways (start with one way, find the end node > as the start node of another way and so on), but then rendering would be > as per any other polygon. > > It's a bit fiddly, but it removes the problems of the > artificial connections across the water not eing idetifiable while at the > same time still providing a complete polygon (albeit indirectly) for the > renderer to work on. > You mean like http://wiki.openstreetmap.org/index.php/Relations/Proposed/Rivers, which would be my ideal, but I'm just not sure Mapnik and [EMAIL PROTECTED], mkgmap, and Kosmos, etc would be able to deal with these. I guess it comes down to two conflicting opinions: 1) are we tagging to match as near as possible what is the real position on the ground, and the renders then have to deal with this; or 2) should our tagging structure make it as easy as possible for the renderers > David > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Polygons and Multipolygons
Hi, > I found the way term 'Multipolygon' is used in OSM context is > confusing. True. What we had been looking for was a term for "polygons with holes"; it seemed unreasonable to create a relation "type=polygon" as plain polygons, without holes, don't require relations. But multipolygon is somewhat of a misnomer. > Shouldn't we be calling MultiPolygon Polygon? There are only 2788 in the database so it would not be too hard to change. I wanted to automatically add the "inner" and "outer" flags to the existing polygons anyway, although they're not strictly required they would make processing easier for some. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular
On 8 Feb 2008, at 11:27, David Earl wrote: > You could do it as a relation. > > The river bank would be a set of ways (each of which shares its end > nodes with the ends of one of the others), and you could have a > role for the one or two ways which close the loop which says "this > is structural, not really part of the river bank". The renderer > would have to assemble the polygon from the constituent ways (start > with one way, find the end node as the start node of another way > and so on), but then rendering would be as per any other polygon. > > It's a bit fiddly, but it removes the problems of the > artificial connections across the water not eing idetifiable while > at the same time still providing a complete polygon (albeit > indirectly) for the renderer to work on. Yes, this sounds reasonable to me. > > David Artem ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Polygons and Multipolygons
Artem Pavlenko wrote:
>Sent: 08 February 2008 11:42 AM
>To: talk Openstreetmap
>Cc: OSM-Dev Openstreetmap
>Subject: [OSM-dev] Polygons and Multipolygons
>
>Hello,
>
>I found the way term 'Multipolygon' is used in OSM context is confusing.
>
>Here are ISO 19125-1 definitions :
>
>1. Polygon
>
>A Polygon is a planar Surface, defined by 1 exterior boundary and 0
>or more interior boundaries. Each
>interior boundary defines a hole in the Polygon.
>
>The assertions for polygons (the rules that define valid polygons) are:
>1. Polygons are topologically closed.
>2. The boundary of a Polygon consists of a set of LinearRings that
>make up its exterior and interior
>boundaries.
>3. No two rings in the boundary cross, the rings in the boundary of a
>Polygon may intersect at a Point but
>only as a tangent :
>" P Î Polygon, " c1, c2 Î P.Boundary(), c1 1 c2, " p, q Î Point, p, q
>Î c1, p 1 q, [ p Î c2 ? q Ï c2]
>4. A Polygon may not have cut lines, spikes or punctures:
>" P Î Polygon, P = Closure(Interior(P))
>5. The Interior of every Polygon is a connected point set.
>6. The Exterior of a Polygon with 1 or more holes is not connected.
>Each hole defines a connected
>component of the Exterior.
>In the above assertions, Interior, Closure and Exterior have the
>standard topological definitions. The
>combination of 1 and 3 make a Polygon a Regular Closed point set.
>
>2. MultiPolygon
>
>A MultiPolygon is a MultiSurface whose elements are Polygons.
>
>The assertions for MultiPolygons are :
>1. The interiors of 2 Polygons that are elements of a MultiPolygon
>may not intersect.
>" M Î MultiPolygon, " Pi, Pj Î M.Geometries(), i1j, Interior(Pi) Ç
>Interior(Pj) = Æ
>2. The Boundaries of any 2 Polygons that are elements of a
>MultiPolygon may not cross and may touch
>at only a finite number of points. (Note that crossing is prevented
>by assertion 1 above).
>" M Î MultiPolygon, " Pi, Pj Î M.Geometries(), " ci Î Pi.Boundaries
>(), cj Î Pj.Boundaries()
>ci Ç cj = {p1,
.., pk | pi Î Point, 1 <= i <= k}
>3. A MultiPolygon is defined as topologically closed.
>4. A MultiPolygon may not have cut lines, spikes or punctures, a
>MultiPolygon is a Regular, Closed point
>set:
>" M Î MultiPolygon, M = Closure(Interior(M))
>5. The interior of a MultiPolygon with more than 1 Polygon is not
>connected, the number of connected
>components of the interior of a MultiPolygon is equal to the number
>of Polygons in the MultiPolygon.
>
>The boundary of a MultiPolygon is a set of closed curves
>(LineStrings) corresponding to the boundaries of
>its element Polygons. Each Curve in the boundary of the MultiPolygon
>is in the boundary of exactly 1
>element Polygon, and every Curve in the boundary of an element
>Polygon is in the boundary of the
>MultiPolygon.
>
>
>It might look quite verbose but it all comes down to very simple fact:
>
>1. What we call Multipolygon is just a Polygon
>2. Multipolygon is a collection of Polygons
>
>
>Shouldn't we be calling MultiPolygon Polygon?
>
Mostly I suspect so. Perhaps the issue came to light when people started to
refer to islands in lakes where there are two polygons, one inside the
other.
Cheers
Andy
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular
- Original Message - From: "Martijn van Oosterhout" <[EMAIL PROTECTED]> To: "David Groom" <[EMAIL PROTECTED]> Cc: Sent: Friday, February 08, 2008 11:10 AM Subject: Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular > On Feb 8, 2008 11:39 AM, David Groom <[EMAIL PROTECTED]> wrote: >> The main problem area seems to be that some people do not like the >> current >> proposal whereby a river is divided up in to separate closed areas. The >> reason being that the "segment" crossing the river to close the area >> marks a >> boundary which does not actually exist. Discussion on this could go on >> indefinitely, but it does really need a Mapnik "expert" to either (i) see >> if >> there is a way that Mapnik can render areas which are not closed (ie. >> comprised of two parallel ways), or (ii) if this is not , and will never >> be, >> possible then to state that fact , and we can then have a tag proposal >> which >> will render in both Mapnik and [EMAIL PROTECTED] > > Sure, the same way as coastlines. The question really becomes do we > just want to make waterway=river work the same as coastlines. Mapnik > can't render incomplete polygons the way you want to, and for that > matter neither can osmarender. You get something that vaguely > resembles the end result but in general it won't work. > > *Except* for coastlines, where there is a seperate process that > handles them, for both osmarender and mapnik. > >> The main issue in practice is we now have no standard way of tagging >> rivers, >> and people are relatively free to do what they like, with the result that >> large portions of the River Thames disappeared from the Mapnik layer >> recently >> http://www.informationfreeway.org/?lat=51.49&lon=0.41&zoom=11&layers=F0B0F > > The rules are fairly simple: all areas must be closed, except for > coastlines. People may not like the results, but it's what works right > now. > My point was that while a tag is still only at the proposal stage is a bit difficult to talk of "rules" and tell someone they are doing it "wrong". :) David > Have a nice day, > -- > Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular
On 8 Feb 2008, at 11:26, Andy Allan wrote: > On Feb 8, 2008 11:09 AM, Artem Pavlenko > <[EMAIL PROTECTED]> wrote: > >> We can make osm2pgsql or coastline tools to create polygons, but why >> not create them in the first place ? >> Can someone enlighten me, please ? > > If I wanted to draw the rivers as light blue* with dark blue > riverbanks, wouldn't storing them as polygons would make this hard? I > don't think it would be easy to work out which sections of the > polygons are where the river continues as opposed to being the > riverbank. OK, valid point. > > If we store the riverbanks, then we can pre-process to our hearts > content using osm2pgsql and the like. That way I could have riverbanks > as polylines and rivers as polygons and render them as I see fit. The > pre-processing could work very similarly to the coastlines, using a > left- or right-hand side rule and continuing the riverbank where one > way joins onto the next to construct the polygons required. Can relations help here ? > > Cheers, > Andy > > * As I think more and more about contours, and semi-transparent > renderings and so on I realise that most area-fills will be > translucent with edges on my maps, so we need to avoid abutting > polygons if we aren't intending to represent an edge. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Polygons and Multipolygons
Hello,
I found the way term 'Multipolygon' is used in OSM context is confusing.
Here are ISO 19125-1 definitions :
1. Polygon
A Polygon is a planar Surface, defined by 1 exterior boundary and 0
or more interior boundaries. Each
interior boundary defines a hole in the Polygon.
The assertions for polygons (the rules that define valid polygons) are:
1. Polygons are topologically closed.
2. The boundary of a Polygon consists of a set of LinearRings that
make up its exterior and interior
boundaries.
3. No two rings in the boundary cross, the rings in the boundary of a
Polygon may intersect at a Point but
only as a tangent :
" P Î Polygon, " c1, c2 Î P.Boundary(), c1 1 c2, " p, q Î Point, p, q
Î c1, p 1 q, [ p Î c2 ? q Ï c2]
4. A Polygon may not have cut lines, spikes or punctures:
" P Î Polygon, P = Closure(Interior(P))
5. The Interior of every Polygon is a connected point set.
6. The Exterior of a Polygon with 1 or more holes is not connected.
Each hole defines a connected
component of the Exterior.
In the above assertions, Interior, Closure and Exterior have the
standard topological definitions. The
combination of 1 and 3 make a Polygon a Regular Closed point set.
2. MultiPolygon
A MultiPolygon is a MultiSurface whose elements are Polygons.
The assertions for MultiPolygons are :
1. The interiors of 2 Polygons that are elements of a MultiPolygon
may not intersect.
" M Î MultiPolygon, " Pi, Pj Î M.Geometries(), i1j, Interior(Pi) Ç
Interior(Pj) = Æ
2. The Boundaries of any 2 Polygons that are elements of a
MultiPolygon may not ‘cross’ and may touch
at only a finite number of points. (Note that crossing is prevented
by assertion 1 above).
" M Î MultiPolygon, " Pi, Pj Î M.Geometries(), " ci Î Pi.Boundaries
(), cj Î Pj.Boundaries()
ci Ç cj = {p1, ….., pk | pi Î Point, 1 <= i <= k}
3. A MultiPolygon is defined as topologically closed.
4. A MultiPolygon may not have cut lines, spikes or punctures, a
MultiPolygon is a Regular, Closed point
set:
" M Î MultiPolygon, M = Closure(Interior(M))
5. The interior of a MultiPolygon with more than 1 Polygon is not
connected, the number of connected
components of the interior of a MultiPolygon is equal to the number
of Polygons in the MultiPolygon.
The boundary of a MultiPolygon is a set of closed curves
(LineStrings) corresponding to the boundaries of
its element Polygons. Each Curve in the boundary of the MultiPolygon
is in the boundary of exactly 1
element Polygon, and every Curve in the boundary of an element
Polygon is in the boundary of the
MultiPolygon.
It might look quite verbose but it all comes down to very simple fact:
1. What we call Multipolygon is just a Polygon
2. Multipolygon is a collection of Polygons
Shouldn't we be calling MultiPolygon Polygon?
Artem
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Polygons and Multipolygons
On 8 Feb 2008, at 11:46, Andy Robinson ((blackadder)) wrote:
> Artem Pavlenko wrote:
>> Sent: 08 February 2008 11:42 AM
>> To: talk Openstreetmap
>> Cc: OSM-Dev Openstreetmap
>> Subject: [OSM-dev] Polygons and Multipolygons
>>
>> Hello,
>>
>> I found the way term 'Multipolygon' is used in OSM context is
>> confusing.
>>
>> Here are ISO 19125-1 definitions :
>>
>> 1. Polygon
>>
>> A Polygon is a planar Surface, defined by 1 exterior boundary and 0
>> or more interior boundaries. Each
>> interior boundary defines a hole in the Polygon.
>>
>> The assertions for polygons (the rules that define valid polygons)
>> are:
>> 1. Polygons are topologically closed.
>> 2. The boundary of a Polygon consists of a set of LinearRings that
>> make up its exterior and interior
>> boundaries.
>> 3. No two rings in the boundary cross, the rings in the boundary of a
>> Polygon may intersect at a Point but
>> only as a tangent :
>> " P Î Polygon, " c1, c2 Î P.Boundary(), c1 1 c2, " p, q Î Point, p, q
>> Î c1, p 1 q, [ p Î c2 ? q Ï c2]
>> 4. A Polygon may not have cut lines, spikes or punctures:
>> " P Î Polygon, P = Closure(Interior(P))
>> 5. The Interior of every Polygon is a connected point set.
>> 6. The Exterior of a Polygon with 1 or more holes is not connected.
>> Each hole defines a connected
>> component of the Exterior.
>> In the above assertions, Interior, Closure and Exterior have the
>> standard topological definitions. The
>> combination of 1 and 3 make a Polygon a Regular Closed point set.
>>
>> 2. MultiPolygon
>>
>> A MultiPolygon is a MultiSurface whose elements are Polygons.
>>
>> The assertions for MultiPolygons are :
>> 1. The interiors of 2 Polygons that are elements of a MultiPolygon
>> may not intersect.
>> " M Î MultiPolygon, " Pi, Pj Î M.Geometries(), i1j, Interior(Pi) Ç
>> Interior(Pj) = Æ
>> 2. The Boundaries of any 2 Polygons that are elements of a
>> MultiPolygon may not ‘cross’ and may touch
>> at only a finite number of points. (Note that crossing is prevented
>> by assertion 1 above).
>> " M Î MultiPolygon, " Pi, Pj Î M.Geometries(), " ci Î Pi.Boundaries
>> (), cj Î Pj.Boundaries()
>> ci Ç cj = {p1, ….., pk | pi Î Point, 1 <= i <= k}
>> 3. A MultiPolygon is defined as topologically closed.
>> 4. A MultiPolygon may not have cut lines, spikes or punctures, a
>> MultiPolygon is a Regular, Closed point
>> set:
>> " M Î MultiPolygon, M = Closure(Interior(M))
>> 5. The interior of a MultiPolygon with more than 1 Polygon is not
>> connected, the number of connected
>> components of the interior of a MultiPolygon is equal to the number
>> of Polygons in the MultiPolygon.
>>
>> The boundary of a MultiPolygon is a set of closed curves
>> (LineStrings) corresponding to the boundaries of
>> its element Polygons. Each Curve in the boundary of the MultiPolygon
>> is in the boundary of exactly 1
>> element Polygon, and every Curve in the boundary of an element
>> Polygon is in the boundary of the
>> MultiPolygon.
>>
>>
>> It might look quite verbose but it all comes down to very simple
>> fact:
>>
>> 1. What we call Multipolygon is just a Polygon
>> 2. Multipolygon is a collection of Polygons
>>
>>
>> Shouldn't we be calling MultiPolygon Polygon?
>>
>
> Mostly I suspect so. Perhaps the issue came to light when people
> started to
> refer to islands in lakes where there are two polygons, one inside the
> other.
>
Yes, I can see that. I guess this won't be a problem if we use, say
'SuperPolygon' or something (I'm not suggesting this)
> Cheers
>
> Andy
>
Artem
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular
On Feb 8, 2008 11:39 AM, David Groom <[EMAIL PROTECTED]> wrote: > The main problem area seems to be that some people do not like the current > proposal whereby a river is divided up in to separate closed areas. The > reason being that the "segment" crossing the river to close the area marks a > boundary which does not actually exist. Discussion on this could go on > indefinitely, but it does really need a Mapnik "expert" to either (i) see if > there is a way that Mapnik can render areas which are not closed (ie. > comprised of two parallel ways), or (ii) if this is not , and will never be, > possible then to state that fact , and we can then have a tag proposal which > will render in both Mapnik and [EMAIL PROTECTED] Sure, the same way as coastlines. The question really becomes do we just want to make waterway=river work the same as coastlines. Mapnik can't render incomplete polygons the way you want to, and for that matter neither can osmarender. You get something that vaguely resembles the end result but in general it won't work. *Except* for coastlines, where there is a seperate process that handles them, for both osmarender and mapnik. > The main issue in practice is we now have no standard way of tagging rivers, > and people are relatively free to do what they like, with the result that > large portions of the River Thames disappeared from the Mapnik layer > recently > http://www.informationfreeway.org/?lat=51.49&lon=0.41&zoom=11&layers=F0B0F The rules are fairly simple: all areas must be closed, except for coastlines. People may not like the results, but it's what works right now. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular
On 8 Feb 2008, at 10:39, David Groom wrote: > The proposed tag waterway = river, > http://wiki.openstreetmap.org/index.php/Proposed_features/ > Large_rivers , has > been at proposal stage for over 18 months, which seems far too long > for a > tag which represents such an important feature. > > The main problem area seems to be that some people do not like the > current > proposal whereby a river is divided up in to separate closed areas. Representing features (like rivers) as well-formed closed polygon sounds good to me. > The > reason being that the "segment" crossing the river to close the > area marks a > boundary which does not actually exist. Discussion on this could > go on > indefinitely, but it does really need a Mapnik "expert" to either > (i) see if > there is a way that Mapnik can render areas which are not closed (ie. > comprised of two parallel ways), Of course there is a way, but I'm not convinced at all we should take this approach. > or (ii) if this is not , and will never be, > possible then to state that fact , and we can then have a tag > proposal which > will render in both Mapnik and [EMAIL PROTECTED] We can make osm2pgsql or coastline tools to create polygons, but why not create them in the first place ? Can someone enlighten me, please ? > > The main issue in practice is we now have no standard way of > tagging rivers, > and people are relatively free to do what they like, with the > result that > large portions of the River Thames disappeared from the Mapnik layer > recently > http://www.informationfreeway.org/? > lat=51.49&lon=0.41&zoom=11&layers=F0B0F As a short term solution we can replace problematic coastline tile in London (100x100km vectors) with old one, I guess. > > David > Artem > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular
David Groom wrote: >Sent: 08 February 2008 10:40 AM >To: talk@openstreetmap.org >Subject: [OSM-talk] Large Rivers in general, mapnik rendering in Particular > >The proposed tag waterway = river, >http://wiki.openstreetmap.org/index.php/Proposed_features/Large_rivers , >has >been at proposal stage for over 18 months, which seems far too long for a >tag which represents such an important feature. > >The main problem area seems to be that some people do not like the current >proposal whereby a river is divided up in to separate closed areas. The >reason being that the "segment" crossing the river to close the area marks >a >boundary which does not actually exist. Discussion on this could go on >indefinitely, but it does really need a Mapnik "expert" to either (i) see >if >there is a way that Mapnik can render areas which are not closed (ie. >comprised of two parallel ways), or (ii) if this is not , and will never >be, >possible then to state that fact , and we can then have a tag proposal >which >will render in both Mapnik and [EMAIL PROTECTED] > >The main issue in practice is we now have no standard way of tagging >rivers, >and people are relatively free to do what they like, with the result that >large portions of the River Thames disappeared from the Mapnik layer >recently >http://www.informationfreeway.org/?lat=51.49&lon=0.41&zoom=11&layers=F0 >B0F > As time goes on this is going to be an issue that comes up more and more frequently. Thankfully OSM has a much simpler approach to data than a full blown GIS approach where all edge features are tagged. In OSM we accept a certain degree of simplification (roads are created as regular liner features even if their width actually varies). I was looking at the Rotterdam area yesterday: http://www.openstreetmap.org/?lat=51.7578&lon=4.7882&zoom=13&layers=B0FT and it was clear that rivers and other water courses are not ideally served by regular linear rendering. With the exception of canals, which on the whole have pretty regular width with length, rivers, streams and many other water courses do not and we should therefore arguably always think of them as areas. So where we have the required information we should always attempt to create area rendering rather than regular liner lines. Requiring closed areas though is not ideal for many reasons so achieving rendering between defined objects, whether by relationship or otherwise would seem logical to me. Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Uploading non-GPX files
Hello all, In case anyone else finds it useful... I've knocked up a short webform that enables you to upload tracklogs to OSM in other formats than GPX. It does the conversion for you, then uploads the resulting GPX file. It might be useful if, say, you have a NaviGPS and have copied the NMEA tracklogs off the SD card. http://richard.dev.openstreetmap.org/upload.cgi Made possible by TomH fixing http://trac.openstreetmap.org/ticket/670 in record time - thanks Tom. :) cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] correctly mapping avenues
On 08/02/2008 16:43, Iván Sánchez Ortega wrote: > <-- <-- <-- <-- <-- highway = service > Tree Tree Tree Tree amenity = park err... leisure=park ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] correctly mapping avenues
bvh wrote: > On Fri, Feb 08, 2008 at 04:52:55PM +, David Earl wrote: >> On 08/02/2008 16:43, Iván Sánchez Ortega wrote: >>> <-- <-- <-- <-- <-- highway = service >>> Tree Tree Tree Tree amenity = park >> err... leisure=park > > err... is a line of trees a park? it ususally is just a line of trees. this piture: http://upload.wikimedia.org/wikipedia/commons/thumb/7/74/Corso_Vittorio_Emanuele_II_Torino.JPG/400px-Corso_Vittorio_Emanuele_II_Torino.JPG should give the idea. Enrico ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] correctly mapping avenues
On 08/02/2008 16:12, bvh wrote: > On Fri, Feb 08, 2008 at 04:52:55PM +, David Earl wrote: >> On 08/02/2008 16:43, Iván Sánchez Ortega wrote: >>> <-- <-- <-- <-- <-- highway = service >>> Tree Tree Tree Tree amenity = park >> err... leisure=park > > err... is a line of trees a park? A bigger question. I see someone has already proposed landuse=tree_row http://wiki.openstreetmap.org/index.php/Proposed_features/tree_row I wanted a tag for miscellaneous bits of open grass with trees and shrubs http://wiki.openstreetmap.org/index.php/Proposed_features/Misc._urban_open_space but the most common comment on the mailing list was "I don't understand what the difference is between this and a park" (though no one has put that in the wiki page). So I gave up, even though I think they are very different. I've tagged my bits of open space as parks even though they aren't. Maybe I should resurrect this. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] correctly mapping avenues
El Viernes, 8 de Febrero de 2008, wiseLYNX escribió: > bvh wrote: > > On Fri, Feb 08, 2008 at 04:52:55PM +, David Earl wrote: > >> On 08/02/2008 16:43, Iván Sánchez Ortega wrote: > >>> <-- <-- <-- <-- <-- highway = service > >>> Tree Tree Tree Tree amenity = park > >> > >> err... leisure=park > > > > err... is a line of trees a park? > > it ususally is just a line of trees. I'm used to see wider green areas as part of big avenues (between the main road and the aux. road). See: http://flickr.com/photos/photomedicamadrid/2171643452/ http://flickr.com/photos/photomedicamadrid/2094446669/ http://flickr.com/photos/zaqarbal/472383597/ http://flickr.com/photos/batiburrillo/140499288/ http://flickr.com/photos/vribeiro/256148375/ All those should use a leisure=park area, IMHO (and it will, as soon as I have some time to do so). If it's *just* a tree line, with no noticeable green area... I guess that the proposed "landuse=tree_row" would apply better. Cheers, -- -- Iván Sánchez Ortega <[EMAIL PROTECTED]> Next Friday will not be your lucky day. As a matter of fact, you don't have a lucky day this year. signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] correctly mapping avenues
El Viernes, 8 de Febrero de 2008, wiseLYNX escribió: > <-- <-- <-- <-- <-- > Tree Tree Tree Tree > <- <- < > > -> -> > Tree Tree Tree Tree > --> --> --> --> --> > Any suggestion about how to render all this? Even an example of an > already done similar object could be useful. Make one way per type of way in the avenue. E.g.: <-- <-- <-- <-- <-- highway = service Tree Tree Tree Tree amenity = park <- <- < highway = primary <- <- < highway = cycleway <- <- < railway = tramway > -> -> railway = tramway > -> -> highway = cycleway > -> -> highway = primary Tree Tree Tree Tree amenity = park --> --> --> --> --> highway = service *If* the central way does *not* have a division between the lanes, then join the two ways, and specify "oneway=false". Just a suggestion, though. -- -- Iván Sánchez Ortega <[EMAIL PROTECTED]> La esperanza es el sueño de un hombre despierto.- Aristóteles. signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] correctly mapping avenues
El Viernes, 8 de Febrero de 2008, wiseLYNX escribió: > can someone have a look at "Corso Massimo d'Azeglio"? Coordinates? -- -- Iván Sánchez Ortega <[EMAIL PROTECTED]> MSN:[EMAIL PROTECTED] Jabber:[EMAIL PROTECTED] ; [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular
- Original Message - From: "Artem Pavlenko" <[EMAIL PROTECTED]> To: "David Earl" <[EMAIL PROTECTED]> Cc: "David Groom" <[EMAIL PROTECTED]>; "talk Openstreetmap" Sent: Friday, February 08, 2008 12:24 PM Subject: Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular > > On 8 Feb 2008, at 12:05, David Earl wrote: > >> On 08/02/2008 11:54, David Groom wrote: >>> You mean like >>> http://wiki.openstreetmap.org/index.php/Relations/Proposed/Rivers, >>> which >>> would be my ideal, >> >> Ah, yes. >> >> I was suggesting putting in the connections across the river as well, >> but there isn't any reason why if the renderer is building its own >> polygon from the relation that it can't imply a connection from the end >> of each way to the start of the other. >> >> Allowing more than one contiguous way on each bank would also be useful. > > >> I'll edit the wiki. > > Could you put some visual examples, please? Artem, what i had in mind is now shown on http://wiki.openstreetmap.org/index.php/Relations/Proposed/Rivers David G >> >> David > > Artem >> >> ___ >> talk mailing list >> talk@openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-legal-talk] [OSM-talk] Progressing OSM to a new dataLicence regime
Robert (Jamie) Munro wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Gervase Markham wrote: > | Robert (Jamie) Munro wrote: > |> It's been proposed by me several times in the past. I think it's > |> essential. I don't know of a similar major project that doesn't do some > |> kind of assignment. Wikipedia is the nearest, but Wikipedia is a > |> collection of articles that all stand on their own. > > I didn't make it clear that I want a non-exclusive, non-revokable > license to the foundation, rather than "assignment" as such. This is > important, for example, for the case of map data collected as a side > product of collecting some commercial data. There's no question that you > can still use your data for whatever you want. > > | Can you name some which do? > > ~ * MusicBrainz.org > ~ * voxforge.org > > Then there's lots of code projects like Mozilla, apache, etc. and also > semi-free projects like dmoz.org, peoples map etc. I think I can speak with some authority when I say that Mozilla does not require copyright assignment of any sort :-) Apache requires the type of "rights sharing" you mention. > | But surely a license is a codification of "what everyone agrees it > | should be allowed for"? > > In theory yes, but based on how long we've been discussing this issue, > it can never be in practise. Surely the length of discussion is symptomatic of the fact that there is actually some disagreement about "what everyone agrees it should be allowed for" (your phrase)? > | There are negative sides to a copyright assignment. A) We probably > | wouldn't get one from e.g. AND or MASSGIS (although I'm speculating). > > We could handle large data donations specially. All contributors are equal, but some are more equal than others? > How do we know that AND and MASSGIS will support our current proposed > license change? I assume that the OSMF has sounded them out. They have told us, at least, that the removal of SA would cause a rethink, which implies that there has been communication. > | B) > | It would mean the scenario I mentioned to Frederik, where a commercial > | company could sue a license violator, couldn't happen, because they > | would no longer be the copyright holder. > > If they are suing over a part of the data they contributed, they would > be joint copyright holders. They would be entitled to damages along with > the foundation. Actually, under the scheme you propose above, they would not be joint copyright holders - copyright would remain with the original contributor. But yes, if we did what you propose, then the suing would still be possible. Gerv ___ legal-talk mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/legal-talk
Re: [OSM-talk] correctly mapping avenues
On Fri, Feb 08, 2008 at 04:52:55PM +, David Earl wrote: > On 08/02/2008 16:43, Iván Sánchez Ortega wrote: > > <-- <-- <-- <-- <-- highway = service > > Tree Tree Tree Tree amenity = park > err... leisure=park err... is a line of trees a park? cu bart ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] correctly mapping avenues
Hi everybody, my quest to map Torino continues, and yesterday I was gratified by seeing the first update of the rendered map containing my work. I have a question though. Torino is full of wonderful wide avenues, with a central two way lane, and two one way lane on the sides. something like this little ascii art: <-- <-- <-- <-- <-- Tree Tree Tree Tree <- <- < > -> -> Tree Tree Tree Tree --> --> --> --> --> To make things more complicated, central lanes are often double lanes, there are often tramway rails, or buses reserved lanes; sometimes cycleway tracks. Any suggestion about how to render all this? Even an example of an already done similar object could be useful. thanks in advance, Enrico ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular
On 8 Feb 2008, at 12:05, David Earl wrote: > On 08/02/2008 11:54, David Groom wrote: >> You mean like >> http://wiki.openstreetmap.org/index.php/Relations/Proposed/Rivers, >> which >> would be my ideal, > > Ah, yes. > > I was suggesting putting in the connections across the river as well, > but there isn't any reason why if the renderer is building its own > polygon from the relation that it can't imply a connection from the > end > of each way to the start of the other. > > Allowing more than one contiguous way on each bank would also be > useful. > I'll edit the wiki. Could you put some visual examples, please? > > David Artem > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Polygons and Multipolygons
On 8 Feb 2008, at 11:50, Frederik Ramm wrote: > Hi, > >> I found the way term 'Multipolygon' is used in OSM context is >> confusing. > > True. What we had been looking for was a term for "polygons with > holes"; it seemed unreasonable to create a relation "type=polygon" > as plain polygons, without holes, don't require relations. But > multipolygon is somewhat of a misnomer. > >> Shouldn't we be calling MultiPolygon Polygon? > > There are only 2788 in the database so it would not be too hard to > change. I wanted to automatically add the "inner" and "outer" flags > to the existing polygons anyway, although they're not strictly > required they would make processing easier for some. I think having 'outer' and 'inner' flags/tags will help at the data entry stage as well. > > Bye > Frederik > > -- > Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008° > 23.33' > Artem > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular
On Feb 8, 2008 12:47 PM, David Groom <[EMAIL PROTECTED]> wrote: > > The rules are fairly simple: all areas must be closed, except for > > coastlines. People may not like the results, but it's what works right > > now. > > > My point was that while a tag is still only at the proposal stage is a bit > difficult to talk of "rules" and tell someone they are doing it "wrong". :) Ok, by "rules" I meant: this is how it works now. Since the whole tag proposal thing isn't official anyway, talking about what might happen is silly. The only rules that matter is what actually works right now... Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] New Coastline in Mapnik - Glasgow cIty center issue
On Fri, 2008-02-08 at 10:17 +, David Groom wrote: > > Thanks to all for working on this! The River Clyde in Glasgow is almost > > perfect now. I say almost because there seems to be an issue between > > Bridge Street/A77 and the A74: > > > > http://www.openstreetmap.org/?lat=55.85324&lon=-4.25218&zoom=15&layers=B0FT > > > > I've just upgraded my system so i don't have JOSM running at the moment, > > it would be great if someone could take a look and fix this. > > Fixed This was intentional as I thought the river was tidal up to Bridge Street (but it isn't). -- Bruce Cowan <[EMAIL PROTECTED]> ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular
On 08/02/2008 11:54, David Groom wrote: > You mean like > http://wiki.openstreetmap.org/index.php/Relations/Proposed/Rivers, which > would be my ideal, Ah, yes. I was suggesting putting in the connections across the river as well, but there isn't any reason why if the renderer is building its own polygon from the relation that it can't imply a connection from the end of each way to the start of the other. Allowing more than one contiguous way on each bank would also be useful. I'll edit the wiki. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular
You could do it as a relation. The river bank would be a set of ways (each of which shares its end nodes with the ends of one of the others), and you could have a role for the one or two ways which close the loop which says "this is structural, not really part of the river bank". The renderer would have to assemble the polygon from the constituent ways (start with one way, find the end node as the start node of another way and so on), but then rendering would be as per any other polygon. It's a bit fiddly, but it removes the problems of the artificial connections across the water not eing idetifiable while at the same time still providing a complete polygon (albeit indirectly) for the renderer to work on. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-legal-talk] [OSM-talk] Progressing OSM to a new dataLicence regime
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gervase Markham wrote: | Robert (Jamie) Munro wrote: |> It's been proposed by me several times in the past. I think it's |> essential. I don't know of a similar major project that doesn't do some |> kind of assignment. Wikipedia is the nearest, but Wikipedia is a |> collection of articles that all stand on their own. I didn't make it clear that I want a non-exclusive, non-revokable license to the foundation, rather than "assignment" as such. This is important, for example, for the case of map data collected as a side product of collecting some commercial data. There's no question that you can still use your data for whatever you want. | Can you name some which do? ~ * MusicBrainz.org ~ * voxforge.org Then there's lots of code projects like Mozilla, apache, etc. and also semi-free projects like dmoz.org, peoples map etc. |> We need a situation where someone can say "Yes" when an enquiry comes |> in, not "hire a lawyer to look at license XYZ". Otherwise the data is |> useless for many purposes that everyone would agree it should be allowed |> for. | | But surely a license is a codification of "what everyone agrees it | should be allowed for"? In theory yes, but based on how long we've been discussing this issue, it can never be in practise. |> For example, a while ago, ITN news needed a map of Baghdad. No one could |> say for sure how much of the TV buletin they would have to release |> CC-by-sa in order to allow them to do that. Looking back at that now, |> probably "only" the final ITN styled bitmap image that is shown on the |> screen, but the designers of ITN's style guidelines probably haven't |> licensed ITN to release them. |> |> If the foundation owned the data, they could say to ITN "just show a |> logo and www.openstreetmap.org in the corner at some point", and |> everyone would be happy. | | As I understand it, the new licence solves this problem. It might solve /that/ problem, but it will not solve all problems. |> Another example: it would be great if an npemap type system could be |> used with OSM maps to derive a free postcode database, but license |> incompatibilities make that impossible. This is insane. | | (Define "free".) You may think so. Other contributors may think it's | entirely reasonable for postcode data calculated using OSM to be BY-SA | rather than PD. In this case PD. FTP is PD, npemaps postcodes are PD. |> Obviously if |> that went to any kind of vote, the foundation would allow that, but they |> don't currently have the power to allow it. | | It would certainly be interesting to look at whether the licence change | would have any effect on the postcode problem. | |> Yes, maybe you can come up with a license that would unambiguously allow |> the above two uses, but there will be cases where it will be in OSM's |> interests to bend the rules, and we must provide a mechanism that allows |> this. | | There are negative sides to a copyright assignment. A) We probably | wouldn't get one from e.g. AND or MASSGIS (although I'm speculating). We could handle large data donations specially. If there were 3 or 4 organisations we had to ask (and normally only 1 per geographic area) before we could use the data for an unforseen purpose, that's a lot easier than having to contact potentially thousands of contributors each time. How do we know that AND and MASSGIS will support our current proposed license change? | B) | It would mean the scenario I mentioned to Frederik, where a commercial | company could sue a license violator, couldn't happen, because they | would no longer be the copyright holder. If they are suing over a part of the data they contributed, they would be joint copyright holders. They would be entitled to damages along with the foundation. They could also help the foundation with legal costs or something. I'm not sure of the law, but maybe they could sue on the grounds that they lost money due to a third parties illegal actions, even if the actions weren't against them directly. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHrKdgz+aYVHdncI0RAo0xAKCbFFDPXTYpo+JfCC5sYvgtrYMS1ACg/TcX 4mU1f4iqyC17p7lImTkkGW0= =qK4y -END PGP SIGNATURE- ___ legal-talk mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/legal-talk
Re: [OSM-talk] correctly mapping avenues
Iván Sánchez Ortega wrote: > El Viernes, 8 de Febrero de 2008, wiseLYNX escribió: >> <-- <-- <-- <-- <-- >> Tree Tree Tree Tree >> <- <- < >> > -> -> >> Tree Tree Tree Tree >> --> --> --> --> --> > >> Any suggestion about how to render all this? Even an example of an >> already done similar object could be useful. > > Make one way per type of way in the avenue. E.g.: > > > <-- <-- <-- <-- <-- highway = service > Tree Tree Tree Tree amenity = park > <- <- < highway = primary > <- <- < highway = cycleway > <- <- < railway = tramway > > -> -> railway = tramway > > -> -> highway = cycleway > > -> -> highway = primary > Tree Tree Tree Tree amenity = park > --> --> --> --> --> highway = service > > *If* the central way does *not* have a division between the lanes, then join > the two ways, and specify "oneway=false". > > Just a suggestion, though. > (I'm not if this can be done, as it's not rendered and I don't know if Potlatch will let others see what I just changed) can someone have a look at "Corso Massimo d'Azeglio" (I checked, OSM gives only the right occurrence) is right following your suggestions? It is an avenue with separated double one-way lanes, with a tree line in the middle, which crosses several two-way streets. In ascii art: BUILDING BUILDING <-- <-- <-- <-- < <--- <--- <--- <- tree tree tree tr ---> ---> ---> -- --> --> --> --> - park park park pa thanks, Enrico ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] correctly mapping avenues
On 09/02/2008, Iván Sánchez Ortega <[EMAIL PROTECTED]> wrote: > El Viernes, 8 de Febrero de 2008, wiseLYNX escribió: > > <-- <-- <-- <-- <-- > > Tree Tree Tree Tree > > <- <- < > > > -> -> > > Tree Tree Tree Tree > > --> --> --> --> --> > > > Any suggestion about how to render all this? Even an example of an > > already done similar object could be useful. there are loads of these in melbourne, australia. here's an example near st kilda http://openstreetmap.org/?lat=-37.841299&lon=144.977815&zoom=18&layers=B0FT with a tramway down the middle > Make one way per type of way in the avenue. E.g.: > > > <-- <-- <-- <-- <-- highway = service a service road is different and not for busy, it's really for alley ways or small lanes between/behind shops. very inappropriate here just draw a single, oneway st, tagged with the same name and ref as the main part > Tree Tree Tree Tree amenity = park a park has a specific meaning, decided by the local (or regional) council. it implies lots of bylaws, etc. this is not a park unless it's explicitly marked as such. it's just a verge i think landuse = row_of_trees or whatever was suggested, is a hideous abuse of the landuse tag. landuse isn't there as a dumping ground for things that taggers can't be bothered to categorise properly there is a tag proposal called natural=life, which may be the way to go with this, but it's not finalised yet > <- <- < highway = primary > <- <- < highway = cycleway > <- <- < railway = tramway > > -> -> railway = tramway > > -> -> highway = cycleway > > -> -> highway = primary > Tree Tree Tree Tree amenity = park > --> --> --> --> --> highway = service > > *If* the central way does *not* have a division between the lanes, then join > the two ways, and specify "oneway=false". ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
