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.85324lon=-4.25218zoom=15layers=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: talk@openstreetmap.org 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.85324lon=-4.25218zoom=15layers=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.49lon=0.41zoom=11layers=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] [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: talk@openstreetmap.org 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.49lon=0.41zoom=11layers=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
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.49lon=0.41zoom=11layers=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.49lon=0.41zoom=11layers=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.49lon=0.41zoom=11layers=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.7578lon=4.7882zoom=13layers=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
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 talk@openstreetmap.org 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] 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-nl] Fietsroutenetwerk-punten automatiseren?
hoe wil je dit gaan sorteren.. b/r-tree ? geef eens een hint ondertussen ga ik xpath eens pesten Groeten Rob Op 07-02-08 heeft Steven te Brinke [EMAIL PROTECTED] het volgende geschreven: Hallo, XPath is wel heel krachtig, maar niet heel snel. Ik denk dus dat het gebruik van een gesorteerde lijst een beter idee is. Zelf heb ik nog nooit .net gebruikt, dus daar heb ik niet zo veel verstand van. Maar mocht het niet lukken, dan wil ik wel iets in Java schrijven. Daarmee lees ik nu ook al OSM bestanden in. Groeten, Steven Rob schreef: ik heb die wpned-zuid.gpx (1701 waypoints) eens tegen de places.osm(8875) laten draaien, om een indruk te krijgen van performance en dit is een stukje output ... wpt 52C37 close to Pannenschop @ 587m wpt 52C39 close to Vreewijk @ 300m wpt 52C43 close to Leensel @ 714m wpt 52C44 close to Leensel @ 1885m wpt 52C45 close to Heitrak @ 2708m wpt 52C46 close to Ommel @ 50m er wordt dus voor elk wapoint in de gpx de kortsbijzijnde plaats node gevonden in de osm file, hiervoor loopt een dubbele foreach loop, deze berekent de afstand tussen waypoint en node de search loop begint nu al te kraken (lees 155 seconden) aangezien we nu al 15miljoen itteraties hebben. ik ben een andere manier aan het bedenken bereken van elk waypoint de 5meter boundingbox coordinaten en laat de node selectie door xml parser (xpath) doen, dit moet veel efficienter zijn. Op 07-02-08 heeft Rob [EMAIL PROTECTED] het volgende geschreven: dank u, heb nu de netherlands.osm van 600MB dat wordt flink stampen voor xml parser ;) Op 07-02-08 heeft Lambertus [EMAIL PROTECTED] het volgende geschreven: Rob wrote: weet iemand (kleptog?) de locatie van de nederlandse osm file ? heb even op de wiki rondgekeken maar helaas nog niet gevonden Hier staan allemaal up-to-date excerpts: http://download.geofabrik.de/osm/europe/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl -- ___ Talk-nl mailing list [EMAIL PROTECTED]://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Carnavalsnamen
volgens mij moet er nog een meta http-equiv=Content-Type content=text/html; charset=UTF-8/ in de pagina.. Op 08-02-08 heeft Martijn van Exel [EMAIL PROTECTED] het volgende geschreven: maar zie dat er iets misgaat met de interpretatie van speciale karakters, zie voor een voorbeeld http://www.mvexel.dds.nl/schaaltreinen/ZZ485A9319.jpg ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsroutenetwerk-punten automatiseren?
Coördinaten zijn niet makkelijk de sorteren, omdat ze 2-dimensionaal
zijn. Hiermee heb ik ook niet zo veel ervaring. maar ik heb eens
nagedacht wat volgens mij een aardig algoritme is. Ik zal beschrijven
hoe ik het zou implementeren:
Stel we hebben een aantal punten P die niet in OSM zitten. Dan bepalen
we de bouding box van deze punten en nemen alle punten Q die in OSM in
deze bouding box zitten (hierbij kun je je eventueel beperken tot alle
punten met een highway tag).
L := lijst van punten uit Q gesorteerd op OL
p := element uit P, dus punt waarvan we dichtstbijzijnde punt uit Q
willen weten
i := punt met |p.OL - L[i].OL| zo klein mogelijk, deze kun je in
logaritmische tijd vinden
d := afstand(p, L[i])
q := L[i]
j := i + 1;
while ( |p.OL - L[j].OL| d ) {
d2 := afstand(p, L[j])
if ( d2 d ) {
d := d2
q := L[j]
}
j += 1
}
j := i - 1;
while ( |p.OL - L[j].OL| d ) {
d2 := afstand(p, L[j])
if ( d2 d ) {
d := d2
q := L[j]
}
j -= 1
}
return q
Dit algoritme is natuurlijk nog niet volledig, zo moet je nog nadenken
over een paar punten:
* |p.OL - L[j].OL| heeft waarschijnlijk een andere eenheid dan d, dat
moet je even omrekenen
* eventueel kun je in deze while loop i.p.v. tegen d, degen minimum(d,
MAX-AFSTAND) controleren
* ik heb het hier over een gesorteerde lijst, maar een boom zou ook
kunnen, als je er maar in order doorheen kunt lopen (een boom laad wel
veel sneller dan een lijst, maar aangezien je hier één keer deze
lijst/boom laad en daarna voor alle punten de dichtstbijzijnde kunt
vinden, is de snelheid van het laden niet heel belangrijk)
Mocht je nog een werkende XPath versie hebben, dan hoor ik graag of de
snelheid nog een beetje goed was. De ervaring die ik ermee heb, is dat
het niet heel snel is. Maar dat kan natuurlijk ook (gedeeltelijk) liggen
aan de implementatie die ik gebruik. Misschien heb jij een snellere parser.
Steven
Rob schreef:
hoe wil je dit gaan sorteren.. b/r-tree ? geef eens een hint
ondertussen ga ik xpath eens pesten
Groeten
Rob
Op 07-02-08 heeft *Steven te Brinke* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] het volgende geschreven:
Hallo,
XPath is wel heel krachtig, maar niet heel snel. Ik denk dus dat
het gebruik van een gesorteerde lijst een beter idee is. Zelf heb
ik nog nooit .net gebruikt, dus daar heb ik niet zo veel verstand
van. Maar mocht het niet lukken, dan wil ik wel iets in Java
schrijven. Daarmee lees ik nu ook al OSM bestanden in.
Groeten,
Steven
Rob schreef:
ik heb die wpned-zuid.gpx (1701 waypoints) eens tegen de
places.osm (8875) laten draaien, om een indruk te krijgen van
performance
en dit is een stukje output
...
wpt 52C37 close to Pannenschop @ 587m
wpt 52C39 close to Vreewijk @ 300m
wpt 52C43 close to Leensel @ 714m
wpt 52C44 close to Leensel @ 1885m
wpt 52C45 close to Heitrak @ 2708m
wpt 52C46 close to Ommel @ 50m
er wordt dus voor elk wapoint in de gpx de kortsbijzijnde plaats
node gevonden in de osm file, hiervoor loopt een dubbele foreach
loop, deze berekent de afstand tussen waypoint en node
de search loop begint nu al te kraken (lees 155 seconden)
aangezien we nu al 15miljoen itteraties hebben.
ik ben een andere manier aan het bedenken
bereken van elk waypoint de 5meter boundingbox coordinaten en
laat de node selectie door xml parser (xpath) doen, dit moet
veel efficienter zijn.
Op 07-02-08 heeft *Rob* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] het volgende geschreven:
dank u, heb nu de netherlands.osm van 600MB
dat wordt flink stampen voor xml parser ;)
Op 07-02-08 heeft *Lambertus* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] het volgende geschreven:
Rob wrote:
weet iemand (kleptog?) de locatie van de nederlandse osm
file ?
heb even op de wiki rondgekeken maar helaas nog niet
gevonden
Hier staan allemaal up-to-date excerpts:
http://download.geofabrik.de/osm/europe/
___
Talk-nl mailing list
Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
___
Talk-nl mailing list
Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
___
Talk-nl mailing list
Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Carnavalsnamen
dat ziet er veelbelovend uit ! eerste stap richting een door leken te bedienen webbased editor Op 08-02-08 heeft Martijn van Oosterhout [EMAIL PROTECTED] het volgende geschreven: Ik heb een beetje zitten spelen met een systeem was mensen zelf de namen op zouden kunnen geven. http://tile.openstreetmap.nl/pois.html Nog wat werk aan de winkel, maar het lijkt al ergens op... Mvg, 2008/2/7 Joris Meijerink [EMAIL PROTECTED]: Ik heb van http://www.plezierkapel.nl, toestemming gekregen om hun gegevens te gebruiken. Op de site kunnen plezierkapellen hun contactgegevens plaatsen en in een groot aantal gevallen geven ze ook de carnavalsnaam op van hun plaats. Ik heb een excel-bestand gekregen met 490 namen, waarvan de nodige dubbelen maar we komen weer een stukje verder. gr Joris ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Carnavalsnamen
Martijn, Wat gaaf! Ik heb nu geen tijd om er uitgebreid naar te kijken, maar zie dat er iets misgaat met de interpretatie van speciale karakters, zie voor een voorbeeld http://www.mvexel.dds.nl/schaaltreinen/ZZ485A9319.jpg Nogmaals, UITERMATE cool!!! -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ Op 8 feb 2008, om 11:23 heeft Martijn van Oosterhout het volgende geschreven: Ik heb een beetje zitten spelen met een systeem was mensen zelf de namen op zouden kunnen geven. http://tile.openstreetmap.nl/pois.html Nog wat werk aan de winkel, maar het lijkt al ergens op... Mvg, 2008/2/7 Joris Meijerink [EMAIL PROTECTED]: Ik heb van http://www.plezierkapel.nl, toestemming gekregen om hun gegevens te gebruiken. Op de site kunnen plezierkapellen hun contactgegevens plaatsen en in een groot aantal gevallen geven ze ook de carnavalsnaam op van hun plaats. Ik heb een excel-bestand gekregen met 490 namen, waarvan de nodige dubbelen maar we komen weer een stukje verder. gr Joris ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Carnavalsnamen
Ik heb een beetje zitten spelen met een systeem was mensen zelf de namen op zouden kunnen geven. http://tile.openstreetmap.nl/pois.html Nog wat werk aan de winkel, maar het lijkt al ergens op... Mvg, 2008/2/7 Joris Meijerink [EMAIL PROTECTED]: Ik heb van http://www.plezierkapel.nl, toestemming gekregen om hun gegevens te gebruiken. Op de site kunnen plezierkapellen hun contactgegevens plaatsen en in een groot aantal gevallen geven ze ook de carnavalsnaam op van hun plaats. Ik heb een excel-bestand gekregen met 490 namen, waarvan de nodige dubbelen maar we komen weer een stukje verder. gr Joris ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] Tele Atlas introduceert gps-kaarten voor voetgangers
Ze zijn hun markt ook aan het vergroten. http://life.tweakers.net/nieuws/51771/tele-atlas-introduceert-gps-kaarten-voor-voetgangers.html ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[Talk-de] Worldfile vom 6.2.08
Hallo, das neue Worldfile steht wieder zum Download zur Verfügung. http://wiki.openstreetmap.org/index.php/User:Computerteddy -- Viele Gruesse Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tele Atlas: Navi-Karten für Fußg änger
Hi, Sollte ja mit cGPSmapper gehen. Die Version, die das kann, kostet aber 2800 USD. Vielleicht kann man sich ja zusammen tun. Vielleicht könnte die OSM Foundation eine Lizenz besorgen und die Karten dann für Mitglieder anbieten? Andererseits fördert das natürlich nicht gerade das Entstehen einer freien Alternative... die Idee ist nicht schlecht. Aber ich fände es paradox. Erst kauft man artig ein Stück nicht eben billige Hardware und lizenziert auch noch ebenfalls nicht ganz billiges Kartenmaterial. Dann stellt man fest dass das Kartenmaterial bereits beim Kauf veraltet und recht buggy ist. Ferner bemerkt man, dass die Option am Gerät, Radrouting zu betreiben, den Klick auf die Option nicht wert ist. Also zahlt man ein drittes Mal indem man seine Freizeit in freie Geodaten steckt. Und dann ein viertes Mal, um die jetzt freien Daten in das fehlerhafte Navigationsgerät laden zu können. Ääääh, geht's noch? möchte man fast sagen. Entweder soll Garmin die Docs 'rausrücken wie wir mit OSM-Daten routingfähige Karten bauen können oder ich wechsle auf eine offenere Plattform, für die wir eigene Software bauen können. Nicht zahlen sollten wir für ein Closed-Source-Tool, das dazuhilft den abgeschotteten Garminmarkt noch zu stärken. Damit wir uns nicht falsch verstehen: Es ist das gute Recht der Firma, ihr Datenformat geheim zu halten und ihr (nicht ganz fehlerfreies) Kartenmaterial äußerst restriktiv zu lizenzieren. Andererseits haben die Kunden die Möglichkeit, das nicht zu unterstützen. Beste Grüße, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ?Tele Atlas: Navi-Karten für Fu ßgänger
Christoph Eckert [EMAIL PROTECTED] wrote: Entweder soll Garmin die Docs 'rausrücken wie wir mit OSM-Daten routingfähige Karten bauen können oder ich wechsle auf eine offenere Plattform, für die wir eigene Software bauen können. Wenn es die denn irgendwann mal tatsächlich geben sollte. Das Problem ist, dass es nichts gibt, was die Akkulaufzeit und das wasserdichte Gehäuse eines Garmin einerseits und die features einer offenen Plattform andererseits hat. Nicht mal OpenMoko (falls das irgendwann mal fertig werden sollte) kann diese Bedingungen erfüllen. Mit den Garmin Geräten könnte man daher IMO ganz gut leben, wenn Die Herrschaften sich dazu durchringen könnten ihr Kartenformat zu dokumentieren. Da das aber eine US-(alles ist eine Ware)-Firma ist wird das wohl nix werden. Sven -- In my opinion MS is a lot better at making money than it is at making good operating systems (Linus Torvalds, August 1997) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ?Tele Atlas: Navi-Karten für Fu ßgänger
Christoph Eckert schrieb: Hi, Das Problem ist, dass es nichts gibt, was die Akkulaufzeit und das wasserdichte Gehäuse eines Garmin einerseits und die features einer offenen Plattform andererseits hat. sure. Wobei es mich wundert dass noch nie einer ein robustes, wetterfestes Handy gebaut hat. Gab's doch schon: Siemens ME45! Das ist mir im Laufe der Jahre mehrfach runtergefallen, hat bei mir schon mehrfach einen konkreten Regenschauer auf dem Motorrad überlebt - bislang ohne Murren (mit meiner Digitalkamera hätte ich das lieber nicht probiert). Ist natürlich schein ein paar Jahre älter und von den Features mit aktuellen Handys nicht mehr vergleichbar. Nicht mal OpenMoko (falls das irgendwann mal fertig werden sollte) kann diese Bedingungen erfüllen. Wobei vielleicht hier die Wahrscheinlichkeit noch am höchsten ist, dass in der Richtung mal was geht. Ich kann mir auch gut vorstellen, daß es sowas wie ein Nokia N800 (oder auch einen PDA) auch mal in wasserfest geben wird. Die Integration des GPS ist ja jetzt schon Realität. Dauert vielleicht noch ein paar Jahre, aber das wird schon ... Gruß ULFL P.S: Wir brauchen erstmal eine vernünftig funktionierende Routingsoftware, dann können wir uns über die Wasserfestigkeit der Geräte Gedanken machen ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tele Atlas: Navi-Karten für Fußg änger
Sven Geggus schrieb: Nils Reuter [EMAIL PROTECTED] wrote: Sollte ja mit cGPSmapper gehen. Die Version, die das kann, kostet aber 2800 USD. A temporary description of the Data Routing Format is available here. This is not the final version, but some important information can be found here. http://cgpsmapper.com/download/RFormat_temp.zip Wo steht, dass die $2800 kostet? http://cgpsmapper.com/buy.htm Dort unter Routable cGPSmapper version N. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tele Atlas: Navi-Karten für Fußg änger
Moin, http://cgpsmapper.com/download/RFormat_temp.zip da steht nur, wie man Daten bauen kann, die cgpsmapper dann in routingfähige Garminkarten konvertiert. Dort steht nicht, wie das routingfähige Dateiformat für Garmingeräte aussieht. Unter http://sourceforge.net/projects/garmin-img/ findet sich eine ausführliche Erläuterung des Dateiformates. Wie allerdings Straßensuche und Routing zu bewerkstelligen sind, weiß man noch nicht so genau. Ich fürchte auch, dass sich so schnell niemand die Arbeit machen wird. Schönes Wochenende, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ?Tele Atlas: Navi-Karten für Fu ßgänger
Hi, Das Problem ist, dass es nichts gibt, was die Akkulaufzeit und das wasserdichte Gehäuse eines Garmin einerseits und die features einer offenen Plattform andererseits hat. sure. Wobei es mich wundert dass noch nie einer ein robustes, wetterfestes Handy gebaut hat. Nicht mal OpenMoko (falls das irgendwann mal fertig werden sollte) kann diese Bedingungen erfüllen. Wobei vielleicht hier die Wahrscheinlichkeit noch am höchsten ist, dass in der Richtung mal was geht. Mit den Garmin Geräten könnte man daher IMO ganz gut leben, wenn Die Herrschaften sich dazu durchringen könnten ihr Kartenformat zu dokumentieren. Da das aber eine US-(alles ist eine Ware)-Firma ist wird das wohl nix werden. Sehe ich auch so. Das Kartenformat selbst ist ja per RE dokumentiert. Da Garmin aber mit den routingfähigen Karten gut verdient werden sie so schnell sicher keine Specs 'rausrücken - zumal sie sich ja gerade das ng-Format ausgedacht haben. Einziges neues Feature ist ja scheinbar dass das Format besser komprimiere - wieher... :) Gruß, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Tele Atlas: Navi-Karten für Fußg änger
Hi! Laut heise online wird Tele Atlas demnächst (Oktober) spezielles Kartenmaterial, das für Navigation für Fußgänger ausgelegt ist, anbieten: http://www.heise.de/newsticker/meldung/103210 Naja, mal schauen wie weit wir im Oktober sind! Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tele Atlas: Navi-Karten für Fußg änger
Christoph Eckert schrieb: Entweder soll Garmin die Docs 'rausrücken wie wir mit OSM-Daten routingfähige Karten bauen können oder ich wechsle auf eine offenere Plattform, für die wir eigene Software bauen können. Nicht zahlen sollten wir für ein Closed-Source-Tool, das dazuhilft den abgeschotteten Garminmarkt noch zu stärken. Ich denke, eine offene Plattform wird sich in jedem Fall entwickeln, auch wenn wir alle routingfähige Garminkarten kostenlos haben. Da gibt es einfach genug andere Anreize. Von daher besteht aus meiner Sicht kein Grund, nicht auf cGPSmapper zurückzugreifen, außer dass es mir zu teuer ist. Aber wie gesagt, ein paar Euro wäre es mir schon Wert. Sobald es eine attraktive freie Plattform gibt und eine Neuanschaffung ansteht, werde ich mich auch von Garmin verabschieden. Aber bis dahin würde ich die technischen Möglichkeiten des Geräts gern ausnutzen. Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tele Atlas: Navi-Karten für Fußg änger
Nils Reuter [EMAIL PROTECTED] wrote: Sollte ja mit cGPSmapper gehen. Die Version, die das kann, kostet aber 2800 USD. A temporary description of the Data Routing Format is available here. This is not the final version, but some important information can be found here. http://cgpsmapper.com/download/RFormat_temp.zip Wo steht, dass die $2800 kostet? Vielleicht kann man sich ja zusammen tun. Vielleicht könnte die OSM Foundation eine Lizenz besorgen und die Karten dann für Mitglieder anbieten? Andererseits fördert das natürlich nicht gerade das Entstehen einer freien Alternative... ACK, die Format Doku wäre den Preis eher Wert. Gruss Sven -- In the land of the brave and the free, we defend our freedom with the GNU GPL (Richard M. Stallman on www.gnu.org) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Upload
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Juergen Buchner schrieb: ups .. sorry für die leere Mail ;-) Eigentlich finde ich diesen sofortigen Automatismus nicht so doll. Da ich während der Arbeit öfters zwischenspeichere, werden dann sofort Render-Requests ausgelöst. Gottseidank mit niedriger Prio. Es wird nicht sofort ausgelöst sondern lediglich alle vier Stunden, und zwar aus genau diesem Grund. - -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHrIHeFUbODdpRVDwRAsjCAKDSoku0DWKLb8fNRzk6MjUZ9DspAQCgxe5x wHsxoh0RZqJRpFaYuK6Nc0A= =4fyY -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ?Tele Atlas: Navi-Karten für Fu ßgänger
Am Freitag 08 Februar 2008 schrieb Ulf Lamping: Ich kann mir auch gut vorstellen, daß es sowas wie ein Nokia N800 (oder auch einen PDA) auch mal in wasserfest geben wird. Die Integration des GPS ist ja jetzt schon Realität. naja, zumindest fuer einige pdas gibt's bereits verschiedene gehaeuse fuer den outdoorbereich, teilweise sogar zum tauchen geeignet. sind zwar nicht so schoen und kompakt wie die garmins oder magellans, aber durchaus verfuegbar. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-cz] Mapa silnic podle RSD
Jiri Klement napsal(a): Zdravim, Napsal jsem xslt transformace pro prevod silnic v databance rsd do osm. Nemam samozrejme v umyslu to importovat, je to spis mysleno jako podklad pri kresleni silnic. Je to ke stazeni tady: http://home.zcu.cz/~jklement/osmrsd.zip Vypada to moc pekne a dokonce to i odpovida tem silnicim treti tridy co jsem z RSD opisoval ;-) Ted jeste to jako layer hezky poznat a renderovat ho slabe na pozadi velmi sirokou carou i se jmenem. No, JOSMove pojeti stylu neumi vice pravidel ale v NG bych chtel umet alespon nejaky ten AND, alespon ve smyslu: rule condition k=created_by v=rsdToOsm.xsl/ condition k=highway v=tertiary/ line width=20 colour=#809bc040 annotate=yes/ /rule -- Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [OSM-talk-fr] Re : [Compte-rendu] 1ère r éunion IRC francophone
Arnaud, le centroïde d'une commune, notamment à la campagne, peut être très loin de ce que les habitants considère comme étant le centre de leur commune. D'où l'utilisation de la mairie, de la place importante de la ville/village, etc. Renaud. 2008/2/8 Philippe Piquer [EMAIL PROTECTED]: moi non plus, le mets le point au centre (version 'Darts' après trois choppes) et aussi la ou il n'y a rien. Le 08/02/08, Arnaud CORBET [EMAIL PROTECTED] a écrit : Il a été dit qu'Alban avait une carte avec toutes les limites en vectoriel. Il a été également dit que la place du node qui indique le nom de la commune n'avait pas d'importance. moi je mets le point sur la mairie... Moi pas... ;) Je pense qu'il est préférable, tant qu'on a pas les limites des communes, de placer le point portant le nom de la commune au centroide de la dite commune. Comme ça a déjà été dit, un logiciel de navigation va d'abord chercher une destination dans les limites administratives, à défaut si elles sont pas là dans la zone autour du point portant le nom. Si la mairie est éxentrée, et c'est souvent le cas lorsque les communes se sont offertes une nouvelle mairie ces 20 dernières années, ça va perturber le calcul. En tous cas pas l'aider. Pour signaler la mairie, il y a amenity=townhall _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Re : [Compte-rendu] 1ère r éunion IRC francophone
Personnellement je le place là où moi je considère qu'il s'agisse du centre de la ville. Je prends une vue globale de la ville, je cherche à l'oeil le centre, et je cherche ensuite un coin pas trop chargé où je pourrais y mettre un node sans que ce soit le boxon. 2008/2/8 serge karamazov [EMAIL PROTECTED]: Arnaud, le centroïde d'une commune, notamment à la campagne, peut être très loin de ce que les habitants considère comme étant le centre de leur commune. D'où l'utilisation de la mairie, de la place importante de la ville/village, etc. Renaud. 2008/2/8 Philippe Piquer [EMAIL PROTECTED]: moi non plus, le mets le point au centre (version 'Darts' après trois choppes) et aussi la ou il n'y a rien. Le 08/02/08, Arnaud CORBET [EMAIL PROTECTED] a écrit : Il a été dit qu'Alban avait une carte avec toutes les limites en vectoriel. Il a été également dit que la place du node qui indique le nom de la commune n'avait pas d'importance. moi je mets le point sur la mairie... Moi pas... ;) Je pense qu'il est préférable, tant qu'on a pas les limites des communes, de placer le point portant le nom de la commune au centroide de la dite commune. Comme ça a déjà été dit, un logiciel de navigation va d'abord chercher une destination dans les limites administratives, à défaut si elles sont pas là dans la zone autour du point portant le nom. Si la mairie est éxentrée, et c'est souvent le cas lorsque les communes se sont offertes une nouvelle mairie ces 20 dernières années, ça va perturber le calcul. En tous cas pas l'aider. Pour signaler la mairie, il y a amenity=townhall _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Re : [Compte-rendu] 1ère r éunion IRC francophone
serge karamazov a écrit : Arnaud, le centroïde d'une commune, notamment à la campagne, peut être très loin de ce que les habitants considère comme étant le centre de leur commune. Il y a aussi des mairies complètement excentrée, voir presque en dehors de la ville. (Je pense à un bled à côté de Lannion où ils ont construit une nouvelle mairie au bord de la commune car le bâtiment en centre ville était trop petit) D'où l'utilisation de la mairie, de la place importante de la ville/village, etc. Voila... Au milieu quoi. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
[OSM-talk-fr] Re : Re : [Compte-rendu] 1 ère réunion IRC francophone
A ce moment là je place au centroide de l'agglomération principale, ou au barycentre des différents hameaux suivant leur importance. Et oui, parfois c'est en plein champs (surtout en Normandie, avec son habitat dispersé), mais mon idée est que un logiciel ai le maximum de chances de trouver la destination en cherchant autour du nom de la commune même avec un algorithme primaire. Evidemment, si les limites des communes étaient disponibles, ça simplifierais grandement les choses et le placement de ce node se ferait plutôt sur le bourg principal, pour un rendu plus élégant. - Message d'origine De : serge karamazov [EMAIL PROTECTED] À : Discussions sur OSM en francais talk-fr@openstreetmap.org Envoyé le : Vendredi, 8 Février 2008, 9h36mn 01s Objet : Re: [OSM-talk-fr] Re : [Compte-rendu] 1ère réunion IRC francophone Arnaud, le centroïde d'une commune, notamment à la campagne, peut être très loin de ce que les habitants considère comme étant le centre de leur commune. D'où l'utilisation de la mairie, de la place importante de la ville/village, etc. Renaud. _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] [OSM-talk] Large Rivers in general, mapnik rendering in Particular
The large river problem is also related to the closed coastline one. I don't like having to decide where I close coastlines at the end of a large river. Couldn't we tag riverbank with the same rules as coastline, and let them both be processed by the same pre-processor ? Using this method, coastlines don't have to be closed anymore on estuary. They just have to be connected to a riverbank. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Zones couvertes par Yahoo!
Arnaud CORBET a écrit : Une petite question me vient: est-ce que quelqu'un a la liste des zones couvertes par Yahoo en haute résolution? Yahoo ne la fourni pas, et c'est une liste qui évolue. Il y a une page sur le wiki d'OSM, mais sans aucune garantie d'exhaustivité évidement : http://wiki.openstreetmap.org/index.php/Yahoo%21_Aerial_Imagery/Coverage ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Limites des communes
Salut, Suite à ton message je découvre que la ville de Vannes propose ce PLU en pdf mais aucune mention légale n'y ait jointe. Qu'a t'on le droit de faire avec ce petit pdf ? :) Jérôme BLUM a écrit : Certaines villes mettent à disposition leur PLU au format PDF sur leur site Web. Il peut s'agir d'une bonne source pour récupérer assez précisément les limites communales. Vous pouvez voir un exemple partiel pour la ville de Châtillon : http://www.openstreetmap.org/?lat=48.804lon=2.2892zoom=14layers=0BFT ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Re : [Compte-rendu] 1ère r éunion IRC francophone
Il y a aussi des mairies complètement excentrée, Peut-être faudrait-il créer un thread séparé pour discuter des points restés ouverts pendant la réunion IRC. En attendant, merci à Jonathanmm pour son boulot. A quand la prochaine réunion IRC et avec quel intervalle ? une fois par an ? tous les 6 mois ? tous les 3 mois ? On pourrait déjà ouvrir une liste pour les points possibles à voir (encore que, il a y déjà beaucoup de choses à faire...) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
[OSM-talk-fr] Limites des communes
Certaines villes mettent à disposition leur PLU au format PDF sur leur site Web. Il peut s'agir d'une bonne source pour récupérer assez précisément les limites communales. Vous pouvez voir un exemple partiel pour la ville de Châtillon : http://www.openstreetmap.org/?lat=48.804lon=2.2892zoom=14layers=0BFT ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Limites des communes
Pour délimiter ta ville, tu as utilisé les key boudary et left/right=Clamart Question : - n'aurais tu pas dû plutot utiliser left:city=Clamart ? (ça permet de définir plus facilement plusieurs limites sur un même endroit... limite de ville/département) - ne serait il pas possible d'utiliser ces limites pour, en plus, définir le place ? (ça permettrait de taire la conversation sur le place et le centre de la ville...)... Y'a t'il un moyen d'automatiser cela ? Axel Certaines villes mettent à disposition leur PLU au format PDF sur leur site Web. Il peut s'agir d'une bonne source pour récupérer assez précisément les limites communales. Vous pouvez voir un exemple partiel pour la ville de Châtillon : http://www.openstreetmap.org/?lat=48.804lon=2.2892zoom=14layers=0BFT ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Zones couvertes par Yahoo!
Une première piste : http://wiki.openstreetmap.org/index.php/Yahoo%21_Aerial_Imagery/Coverage Bien entendu très incomplet... On Feb 8, 2008 5:17 PM, Arnaud CORBET [EMAIL PROTECTED] wrote: Une petite question me vient: est-ce que quelqu'un a la liste des zones couvertes par Yahoo en haute résolution? _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [Talk-GB] Scouts Mapping in Central Scotland
Callum Noble wrote: Hi All, I was speaking to someone involved with the Scout Network in Scotland, which is an organisation for ex-Scouts aged 18-25. He suggests a joint mapping weekend/party somewhere in Central Scotland between the Scouts and some OSM contributers. With some of us to give a talk on the project and a demo of how to go about mapping/editing. (They have there own supply of GPS) A brief discussion suggests that this might be better based at a larger town which is pretty blank on the map, rather than in Glasgow/Edinburgh - which for the most part - have their centers mapped quite well now. Falkirk came up as a possibility but anywhere central could work out. I understand they have access to accommodation for themselves in quite a few places - not sure of the exact details of this though. Any Glasgow/Edinburgh/Central Scotland people interested in this? I'm definitly up for this, depending on the dates. Somewhere on the train between Glasgow and Edinburgh, would probably work out well, At a quick glance Livingston and Falkirk might to good places to start. People with cars could head out a little futher afield if neccessary. I'm also more than happy to do a talk in the run up to any event. Anyone in Edinburgh/Glasgow up for some beers in the next few weeks? Cheers Chris ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-gb
Re: [Talk-GB] Greetings and hello GARMIN users - OpenMapSource anyone ?
In message [EMAIL PROTECTED] Mike Paley [EMAIL PROTECTED] wrote: Being ignorant, I don't know what the capabilities and limitations of GPX files are. Apart from tracks, will they take waypoints and routes ? They can, yes. We only use tracks though. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-gb
[Talk-GB] Greetings and hello GARMIN users - OpenMapSource anyone ?
Hi, I see 'openstreetmap' already exists using 'funny' GPX files. For a couple of years now I've been thinking about 'OpenMapSource' - Garmin's MapSource type mapping but 'open' and created by Garmin users - or at least those who can create and handle GDB files. Being ignorant, I don't know what the capabilities and limitations of GPX files are. Apart from tracks, will they take waypoints and routes ? The plan I have has a fair chance of being superior by having more detailed mapping. So, anyone up for discussing my ideas before starting a 'build'? Mike. ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-gb
Re: [Talk-GB] Greetings and hello GARMIN users - OpenMapSource anyone ?
Mike Paley wrote: I see 'openstreetmap' already exists using 'funny' GPX files. For a couple of years now I've been thinking about 'OpenMapSource' - Garmin's MapSource type mapping but 'open' and created by Garmin users - or at least those who can create and handle GDB files. Being ignorant, I don't know what the capabilities and limitations of GPX files are. Apart from tracks, will they take waypoints and routes ? The plan I have has a fair chance of being superior by having more detailed mapping. So, anyone up for discussing my ideas before starting a 'build'? We only use GPX to get tracklogs for tracing from GPS receivers. We don't store anything else as GPX. We don't build tracks, waypoints or routes, we build maps. :) OpenStreetMap data is already in use on Garmin units: http://wiki.openstreetmap.org/index.php/OSM_Map_On_Garmin cheers Richard ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-gb
Re: [Talk-GB] Scouts Mapping in Central Scotland
On Sun, 2008-02-03 at 16:45 +, Callum Noble wrote: Any Glasgow/Edinburgh/Central Scotland people interested in this? As one of the longest term OSM people in Scotland (sorry about boasting), I'd better go on the record saying that I wouldn't be there. I have some major issues at the moment, which is also why I've done very little mapping recently. -- Bruce Cowan [EMAIL PROTECTED] ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-gb
