Re: [OSM-talk] Mapping canals
Hi Gerv - I've snipped lots below - if I haven't commented on any part, I pretty much agree. On Mon, Jan 21, 2008 at 06:36:48PM +, Gervase Markham wrote: Narrow sections are denoted by maxwidth. One narrowboat (just over 7 feet) is given as 2.5m. Two boats is 5m. It's not necessary to mark a two-boat width restriction for bridge holes, which are implied narrow. I don't mind there being an assumption that unspecified units are metres, but the UK canals are done in feet, and if I'm going to put any dimensions in, it'll be in feet, so I'd need a way to specify that's what I'd done. boat=private is used for private parts of the canal. I see no reason not to use access=private, myself, since the towpath can have a seperate access tag. The lock=yes way(s) takes various lock-related information, including: - the lock name, if it has one, with name=foo. since this way is also part of the waterway, name= is already in use for the name of the waterway - we need something else for the lock names. A flight of locks with a unifying name (e.g. Hatton Locks) is denoted with a node placed in an appropriately central position with new tag value place=lock_flight and name=name. Better to group them with a relation, I'd have thought. Moorings Mooring info should be attached to the relevant stretch of towpath [...] On UK canals, mooring is generally allowed everywhere, except where explicity signed otherwise - do we need a tag for mooring-not-allowed? Thanks for thinking this through! s ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] walking routes?
On Jan 22, 2008, at 13:07, [EMAIL PROTECTED] wrote: Nick Whitelegg wrote: TBH I would be fairly dubious about tagging any non-waymarked walks/cycle rides as routes, let alone ones of my own devising. This is interpretation which should be kept out of the largely factual OSM. The data might not fit into the OSM but its still useful. Many websites live from it, e.g. http://www.gps-tour.info/. IMO an easy way to maintain these routes would be to define special tags to the OSM GPS traces database (http://openstreetmap.org/traces). E.g. in this case the tag could be 'recommended_walking_tour'. The trace should contain only the tour and nothing else in this case. A routing application that is aware of these tags could notify the user about nearby recommended tours. But for that purpose, people can use gps-tour.info, right? OSM would be interesting by allowing to present recommended walks, etc. as a sequence of OSM ways. But this data probably would better go into a separate database. I'm sure there's an opportunity for a nice project here: A walks/ rides database that allows to construct such walks by selecting way segments. Perhaps you could also offer a program that approximates uploaded GPX tracks using existing ways, and offer the ability to upload missing ways (or refer to OSM for the last part). I've also been thinking TrailRunner (even better: a free alternative) should allow creating routes from OSM vector data. Cheers Rob ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Mapping canals
Stephen Gower wrote: Hi Gerv - I've snipped lots below - if I haven't commented on any part, I pretty much agree. On Mon, Jan 21, 2008 at 06:36:48PM +, Gervase Markham wrote: Narrow sections are denoted by maxwidth. One narrowboat (just over 7 feet) is given as 2.5m. Two boats is 5m. It's not necessary to mark a two-boat width restriction for bridge holes, which are implied narrow. I don't mind there being an assumption that unspecified units are metres, but the UK canals are done in feet, and if I'm going to put any dimensions in, it'll be in feet, so I'd need a way to specify that's what I'd done. Richard seems to have chimed in with superior knowledge here, so I'll defer to him. Apparently we can use non-metres if we specify. boat=private is used for private parts of the canal. I see no reason not to use access=private, myself, since the towpath can have a seperate access tag. OK... I picked this up because it's defined on the Map Features page. But maybe best practice has moved on since then? The lock=yes way(s) takes various lock-related information, including: - the lock name, if it has one, with name=foo. since this way is also part of the waterway, name= is already in use for the name of the waterway - we need something else for the lock names. Good point. Does this problem have analogies with other sorts of way? How is it dealt with there? A flight of locks with a unifying name (e.g. Hatton Locks) is denoted with a node placed in an appropriately central position with new tag value place=lock_flight and name=name. Better to group them with a relation, I'd have thought. You may be right. I'm not too up on relations. reads Mooring info should be attached to the relevant stretch of towpath [...] On UK canals, mooring is generally allowed everywhere, except where explicity signed otherwise This is true. But there is also a need to mark places where mooring is explicitly provided for or encouraged. (I'm sure you'd agree.) - do we need a tag for mooring-not-allowed? I think we do. Would it be reasonable to have mooring=yes meaning there is explicit mooring here, mooring=no meaning you may not moor, and nothing being well, it's the bank, knock yourself out? Or would that be confusing, given that most other yes/no tags are dual state rather than tri-state? Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Mapping canals
Richard Fairhurst wrote: A few more comments, and like Stephen, I've not commented on those where I agree. Generally we should make sure that tags are applicable to all navigable waterways, so river navigations as well as canals. Sure. If you have correctly tagged a waterway with maxlength and maxwidth, then, there is no need to tag bridges, and lock nodes, with maxlength and maxwidth: this is implied. So you are suggesting we tag the entire canal way with these things, instead of the individual parts and features? That does make sense. I don't particularly want to measure every lock. can be). The channel will typically be more than twice this width. So we need a way of tagging the exceptions - places where only one boat can proceed at once. Something simple like narrows=yes would work, or maybe channel_width=7ft. narrows=yes is normally all that maps show, and any width measurement would be a guesstimate anyway. Do you think that would be sufficient? boat=private is used for private parts of the canal. In Britain, at least, all canals are essentially private. There is no public right of navigation on canals. I see what you're saying, but the terminology will need to be made explicit on the wiki page. Fair point. The wiki page makes some good points, but I suggest we have *both* waterway=lock_gate on nodes (useful for large locks, optional for small ones) and lock=yes on canal/river ways (compulsory, easy to render). I still strongly recommend that lock=yes is optionally applicable to nodes (and whatever the wiki decides, that's how I'll tag). How does that interact with the lock_gate tag? Are you just arguing for a minimalist way of tagging locks, with a single node in the waterway with lock=yes plus any and all ancillary info attached? Or have I misunderstood you? It will make editing _so_ much easier than tagging up countless little ways up the Tardebigge Flight would, and there is no loss of meaning. No-one's saying _you_ have to do this if you don't want to. :-) (In fact, tagging a lock as a way could be misleading. For a UK 70ft lock, the length of the way will typically not be the length of the lock, unless your GPS is really accurate. Elsewhere, locks are generally bigger, and the way approach makes more sense.) Any GPS can distinguish two points 70ft apart, can't they? The same tags can still apply to the node, and the direction is inherited from that of the canal. Isn't there an issue with this directional inheritance, as explained on the wiki page - the renderer has to have special knowledge about which way passing through the lock node is actually the canal. Mooring is on the water so I'd submit it makes more sense to tag the waterway, not the towpath - not least for routing purposes. The side could be indicated by mooring=offside or mooring=towpath. I couldn't work out how to do this well; your solution has promise :-). Would problems arise when there was mooring both sides, perhaps with different restrictions? How would this work for canals without towpaths? Bridges --- New tag: ref_canal_bridge=number for bridge numbers. Just ref_bridge. Some river navigations have bridge numbers, and I wouldn't be too surprised if a few railways did. The reason I went for ref_canal_bridge is that I was concerned about what would happen if a particular bridge had two refs - one allocated by the thing passing underneath, and one by the thing going over the top! For example, all railway bridges (I believe) have a ref; some of them even have them written on in case of a bridge strike. There's such a bridge near me. If a canal passed underneath instead of a road, such a bridge would have two refs. But perhaps this is rare enough for us not to need to care. Amenities - New tag value: amenity=sanitary_station Sanitary station is a really misleading (but sadly widespread) term. If it's misleading, then we can pick a better name. If people want maps saying Sanitary Station, the renderer can translate. Better to group all the constituent services (amenity=pumpout;water_point), BTW, is there a technical limitation which prevents keys having multiple values on an object? Or is that entirely possible, and the above is just how you write it? Or is the above the workaround for the limitation? Is there any agreement on separator character? and to come up with a separate tag for what we refer to as Elsan disposal (a drain where you can empty your Porta-Potti!). amenity=poo_hole could be misconstrued. Elsan's a brand name, so probably best avoided. amenity=excrement_disposal? We have a convention that metric units are used unless you explicitly specify otherwise... but you _can_ explicitly specify if you want to. How far does this go? Furlongs, firkins and fortnights? maxspeed=110 -- assumed km/h maxspeed=70mph -- unit stated maxwidth=2.14 --
Re: [OSM-talk] Mapping canals
On 22/01/2008, Richard Fairhurst [EMAIL PROTECTED] wrote: maxspeed=110 -- assumed km/h maxspeed=70mph -- unit stated maxwidth=2.14 -- assumed metres maxwidht=7ft -- unit stated I'm uneasy about this - up till now, these fields were assumed to contain pure numbers, with the ease of processing that this implies. I know that in an imperial world, it's not so convenient to use a figure like 2.14 when you're trying to represent what could be a round number. But to introduce the possibility of there being units in these fields (and the requirement to arbitrate those units when processing) smacks to me of dirty data. Is there not a nicer middle ground here? I'm thinking of some kind of editor support that would treat units like 'mph', 'ft' or whatever as macros that instantly transform any submitted value into the database internal SI equivalent before submission? Dermot ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Mapping canals
On Jan 22, 2008 2:17 PM, Dermot McNally [EMAIL PROTECTED] wrote: On 22/01/2008, Richard Fairhurst [EMAIL PROTECTED] wrote: maxspeed=110 -- assumed km/h maxspeed=70mph -- unit stated maxwidth=2.14 -- assumed metres maxwidht=7ft -- unit stated I'm uneasy about this - up till now, these fields were assumed to contain pure numbers, with the ease of processing that this implies. I know that in an imperial world, it's not so convenient to use a figure like 2.14 when you're trying to represent what could be a round number. But to introduce the possibility of there being units in these fields (and the requirement to arbitrate those units when processing) smacks to me of dirty data. This is really not difficult to handle. You check for a unit, if you don't understand the unit you pretend the tag didn't exist. If there was no unit you assume metre, and then you convert to whatever unit you happen to be using. It's not dirty, it's just correct. Is there not a nicer middle ground here? I'm thinking of some kind of editor support that would treat units like 'mph', 'ft' or whatever as macros that instantly transform any submitted value into the database internal SI equivalent before submission? And what is the exact SI equivalent of 30mph? I can give you an approximation: 48.28032km/h. What happens though if everyone sticks in 48 instead.. close enough isn't it? Does the difference matter? Probably not for a lot of data uses, but if you're trying to avoid dirty data then you should avoid this kind of forced approximation. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Mapping canals
On Tue, Jan 22, 2008 at 02:25:57PM +, Gervase Markham wrote: Any GPS can distinguish two points 70ft apart, can't they? With up to about a 20m error (which in practice seems to be about right), you might be out by ~65ft. (Granted, both points are likely to be out by the same amount if taken at the same time, but it's still a bit close IMO.) Cheers, -- Matthew ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] map rectifier
On Tue, Jan 22, 2008 at 04:26:06PM +, Steve Chilton wrote: Is the map rectifier working: http://labs.metacarta.com/rectifier/ Nope. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] map rectifier
On 22 Jan 2008, at 16:43, Christopher Schmidt wrote: On Tue, Jan 22, 2008 at 04:26:06PM +, Steve Chilton wrote: Is the map rectifier working: http://labs.metacarta.com/rectifier/ Nope. To save even more typing, next time just use 1 for yes and 0 for no... have fun, SteveC | [EMAIL PROTECTED] | http://www.asklater.com/steve/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Mapping canals
Dave Stubbs wrote: And what is the exact SI equivalent of 30mph? According to the current UK Highway Code, 30mph = 48km/h. I can give you an approximation: 48.28032km/h. What happens though if everyone sticks in 48 instead.. close enough isn't it? If the UK Department for Transport ever finally get around to finishing the metrication project that has been going on since 1862. then 30mph will probably become 50km/h, 60 would become 100km/h, 70mph would become either 110km/h or 120km/h (it's already been lowered, and has become 100km/h for buses, which now need speed limiters set to 100km/h). -- Simon Hewison ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Mapping canals
Dave Stubbs wrote: This is really not difficult to handle. You check for a unit, if you don't understand the unit you pretend the tag didn't exist. So this means that some renderers won't render some values; whereas if we standardised on metres, then all renderers would render all values. Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Mapping canals
On Jan 22, 2008 5:02 PM, Simon Hewison [EMAIL PROTECTED] wrote: Dave Stubbs wrote: And what is the exact SI equivalent of 30mph? According to the current UK Highway Code, 30mph = 48km/h. It's wrong ;-) I can give you an approximation: 48.28032km/h. What happens though if everyone sticks in 48 instead.. close enough isn't it? If the UK Department for Transport ever finally get around to finishing the metrication project that has been going on since 1862. then 30mph will probably become 50km/h, 60 would become 100km/h, 70mph would become either 110km/h or 120km/h (it's already been lowered, and has become 100km/h for buses, which now need speed limiters set to 100km/h). That's all a pretty good explanation of why we need to be adding mph units to keep the data sane! Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] vote closed/proposal approved - cave_entrance
after two weeks of voting, this proposal has been passed with 15 yes votes http://wiki.openstreetmap.org/index.php/Proposed_features/Cave_entrance it will be moved to the approved features and map features page thanks ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Underground lines on the london map
On Tuesday 22 January 2008 07:15:47 J.D. Schmidt wrote: OJW skrev: It's a bit distracting seeing underground train lines overlaid on the [EMAIL PROTECTED] map of London (especially when taking screenshots to use as the base for other maps) -- anyone think they could be removed, and have a separate layer for train/metro connections? (like steve's map of london underground) Why remove them ? Just adjust the stylesheet, so they aren't rendered as prominently, I.E. lighter gray than today for the underground segments of the line. Or in the case of specialtymaps, not rendered at all for the underground segments of the line. Personally I find it beneficiary to have them on the default [EMAIL PROTECTED] map layer. They ensure that the map is more complete and usable for everyday navigation IMHO. At least here in Copenhagen. When looking at the underground in london, I'm seeing things like: * St Pancras underground station not connected to any railway lines * Section of the Circle line missing etc. ...that are very obvious from SteveC2's specialist tube map[1], and on tools like Subway[2], but don't seem to have been noticed during all the time that they were visible on [EMAIL PROTECTED] [1] http://wiki.openstreetmap.org/index.php/Tube_Network_Map [2] http://wiki.openstreetmap.org/index.php/Network_renderer ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Mapping canals
On Jan 22, 2008 5:39 PM, Gervase Markham [EMAIL PROTECTED] wrote: Dave Stubbs wrote: This is really not difficult to handle. You check for a unit, if you don't understand the unit you pretend the tag didn't exist. So this means that some renderers won't render some values; whereas if we standardised on metres, then all renderers would render all values. But some of them will be incorrect. And how do I now make a renderer that gives the speed limit in the unit it's actually specified? Fixing the renderer is relatively simple. The problem is that the world hasn't standardised on km, and it probably won't anytime soon. So yeah, take your pick, but personally I'd prefer correct data. We can of course add another tag, either a tag for a km equivalent value, or a tag for the actual value with units, but I can't imagine many people will bother to fill this in. Dave (last post on this subject) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM gets mentioned in KDE4 keynote speech at Google Headquarters
On Tue, 2008-01-22 at 11:26 +, Artem Pavlenko wrote: I'm on version 0.5 and I get the data by going to File - Download New Data... and installing the Mapnik tiles. They can then be used by chosing OSM Mapnik in the Map View sidebar. Hmm... I compiled 0.6 from source and there's no 'Download New Data..' Artem It looks like you only get it in the KDE-enabled builds, not the plain QTonly application. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] walking routes?
Robert Vollmert wrote: But for that purpose, people can use gps-tour.info, right? OSM would be interesting by allowing to present recommended walks, etc. as a sequence of OSM ways. But this data probably would better go into a separate database. I'm sure there's an opportunity for a nice project here: A walks/ rides database that allows to construct such walks by selecting way segments. Perhaps you could also offer a program that approximates uploaded GPX tracks using existing ways, and offer the ability to upload missing ways (or refer to OSM for the last part). For a routing app its not difficult to fit GPS traces to existing ways. It needs to do this anyway with the current trace. If it has some traces that contain ways that people prefer it could do a better job in selecting a good route. IMO the GPS traces DB would be good source for this. gps-tour.info can't be used due to licensing and it contains few city routes. The effort for now would be to define a set of tags that should be used for this purpose (recommended_walk...). The author of the routing app would need to download these traces and use them to mark some segments as recommended. The data would never be saved in the OSM DB. Grungelborz ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Mapping canals
And what is the exact SI equivalent of 30mph? I can give you an approximation: 48.28032km/h. What happens though if everyone sticks in 48 instead.. close enough isn't it? Nitpicking, but 48.28032 km/h *is* exact. Although in the usual SI unit, 30 mph would be 13.4112 m/s (exactly). Richard B ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM gets mentioned in KDE4 keynote speech at Google Headquarters
On 22 Jan 2008, at 19:50, Matt Williams wrote: On Tuesday 22 January 2008 11:26:53 Artem Pavlenko [EMAIL PROTECTED] wrote: Hi Matt, On Monday 21 January 2008 15:20:41 Andy Allan [EMAIL PROTECTED] wrote: On Jan 21, 2008 10:56 AM, Matt Williams [EMAIL PROTECTED] wrote: Marble already has the ability to download a set of low quality Mapnik tiles (about z=8 or something I guess). Is this just on development versions? I'm running Marble 0.4.0 here, but can't figure out if it can do what you say. Andy I'm on version 0.5 and I get the data by going to File - Download New Data... and installing the Mapnik tiles. They can then be used by chosing OSM Mapnik in the Map View sidebar. Hmm... I compiled 0.6 from source and there's no 'Download New Data..' The version currently in SVN is 0.5 (i.e. there is no 0.6) Yes, there is :D - http://artem.dev.openstreetmap.org/files/ marble-0.6.jpg and talking to someone who compiled it from a checkout thismorning, the menu item should be there. Are you getting the code from SVN or from source packages from somewhere? When compiling Marble, you can choose to either compile the plain Qt4 version or the version that uses the KDE4 libraries. Apparently, the Qt version doesn't have the 'Download New Data..' link so if you want that, you'll need to build the KDE version. To do that, you should follow the Build Marble as a KDE application instructions from http://edu.kde.org/marble/ obtain.php (and of course, you'll need the KDE4 libraries) Yes, thanks, I'm building QT_ONLY version. Artem Matt Artem From what I remember, this was only added very soon before the release of KDE 4.0.0 so I guess that it may only be available in Marble 0.5. If you compiled from source, it's easy to update. Otherwise, I guess you can wait for a distro update. If you want to talk to the developer's directly, you can find them (tackat or ingwa) on the [EMAIL PROTECTED] mailing list or in the #kde-edu channel on irc.freenode.net Matt ___ 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 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM gets mentioned in KDE4 keynote speech at Google Headquarters
On Tuesday 22 January 2008 20:41:33 Artem Pavlenko wrote: On 22 Jan 2008, at 12:59, Torsten Rahn wrote: File - Download New Data (DXS) is one of the very few features that only get enabled if you compile the KDE version (it's a KDE technology). While the MarbleWidget only depends on Qt4 you can have additional features in the menu that get supported throught the KDE framework if you compile it as a KDE4 application. So you probably compiled with -DQTONLY=ON. Yes, I compiled on Mac :) You shouldn't let that stand in your way http://techbase.kde.org/Projects/KDE_on_Mac_OS_X :D Matt Williams ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM gets mentioned in KDE4 keynote speech at Google Headquarters
On 22 Jan 2008, at 20:55, Matt Williams wrote: On Tuesday 22 January 2008 20:41:33 Artem Pavlenko wrote: On 22 Jan 2008, at 12:59, Torsten Rahn wrote: File - Download New Data (DXS) is one of the very few features that only get enabled if you compile the KDE version (it's a KDE technology). While the MarbleWidget only depends on Qt4 you can have additional features in the menu that get supported throught the KDE framework if you compile it as a KDE4 application. So you probably compiled with -DQTONLY=ON. Yes, I compiled on Mac :) You shouldn't let that stand in your way http://techbase.kde.org/Projects/KDE_on_Mac_OS_X :D KDE on Mac, why? I just boot Linux :P A. Matt Williams ___ 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] Mapping canals
On Tue, Jan 22, 2008 at 11:43:25AM +, Richard Fairhurst wrote: Amenities - New tag value: amenity=sanitary_station Sanitary station is a really misleading (but sadly widespread) term. Better to group all the constituent services (amenity=pumpout;water_point), and to come up with a separate tag for what we refer to as Elsan disposal (a drain where you can empty your Porta-Potti!). amenity=poo_hole could be misconstrued. That reminds me of something else I meant to add, which you've partically gone into here - nto all sanitary_stations are equal. You've mentioned some difference, but even with pumpout there's the question of if it's self-operated or not. s ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Expanding the postcode database
Robin Paulson wrote: is that going to cause problems, using any google data would have licensing issues, wouldn't it? Not Google maps data, data from web pages returned by a Google search. I don't think Google puts restrictions on what you can do with information on web pages found using their search, does it? The owner of the web page might technically have a claim, but each address will come from a different page, and anyway, people put their addresses on web pages because they want people to _find_ them, right? That's what we are doing. Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM gets mentioned in KDE4 keynote speech at Google Headquarters
On Jan 22, 2008 9:41 PM, Artem Pavlenko [EMAIL PROTECTED] wrote: I wonder why geographical projection for tiles ? They look quite distorted when warped on sphere: http://artem.dev.openstreetmap.org/files/marble-osm.jpg Maybe spherical Mercator (same as in GMap) would produce better results. Problem is that mercator doesn't work for the poles, which is kinda important for 3D. Also as you get closer to the poles you need to load more tiles to cover the same area. Plate Carre isn't perfect, but it's much better for this purpose. If we setup a tileserver to render in platecarre that might at least fix the stretching, maybe...? 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] Expanding the postcode database
Ray Booysen wrote: I actually have a database lying around somewhere will all possibilities. Quite a high number. Any chance of digging it out and doing SELECT COUNT(*)? Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Expanding the postcode database
On Jan 22, 2008 10:27 PM, Gervase Markham [EMAIL PROTECTED] wrote: Ray Booysen wrote: I actually have a database lying around somewhere will all possibilities. Quite a high number. Any chance of digging it out and doing SELECT COUNT(*)? IIRC 1.8 million. Gerv ___ 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] Mapping canals
Dave Stubbs wrote: But some of them will be incorrect. And how do I now make a renderer that gives the speed limit in the unit it's actually specified? We seem to have a choice between: 1) Making renderers which need to understand the units they want to render on the map, and are capable of converting values in a single standard unit into that rendered unit and rounding appropriately: 48.28 - 29.999mph - 30mph 2) Making renderers which need to understand all possible units anyone might use, and how to convert them into the units they want to render on the map (which may or may not be the units encoded). 50kph - 31.07mph - 30mph 45mph - 45mph - 45mph 73000furlongsperfortnight - 27.16kph - 28kph I opt for 1). I think it's reasonable to ask renderers to know about units they want to render. I don't think it's reasonable to ask them all to know about all possible units anyone might want to stick in the database. Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Mapping canals
On Jan 23, 2008 12:12 AM, Dermot McNally [EMAIL PROTECTED] wrote: So now let's consider items like distances, depths, heights and other items that can be rendered in either metric or imperial (and for all I know, maybe other) units. I happen to be a user of metric measures, so I want to see mountain heights in metres, speeds in km/h and canal lock rises in metres (regardless what country they're in) because those are the units that make sense to me. Up until now, all such units have, by OSM convention, been stored in metric units, which obviously suits me just fine. I think it should also be remembered that metric users outnumber non-metric users by about 19:1 and between imperial users they can't agree on everything (when is a pound not a pound). If we are going to go down this path then we should setup a list of officially permitted non-SI units with designated unit name (so we don't get confusion about 1foot or 2feet), whether 10ft 7 7/16in is allowed (exercise: write a quick parser for that). Is it case sensetive? Not just claiming it's standard (the nice thing about standards is that there's so many to choose from). We could mandate that mph is the only exception, but if we're going to allow exceptions we should list them, because as you can see from the foot example, it's not just multiplying by a factor, you need a parser for some things. 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] Slippymap Hosting Recommendations
On Jan 23, 2008 2:43 AM, Bone Killian [EMAIL PROTECTED] wrote: All I'm really looking for is a place to store tiles I render offline. I plan to cover all of Pennsylvania, which by my back-of-an-envelop calculations would be around 30GB of tiles. If you can run CGI scripts perhaps you can look into some kind of on-the-fly rendering. The NL tileserver has a few layers, but it only takes about 1GB. Remember, most of your diskspace goes into the highest zoom level, which is precisely the level that renders the fastest... 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-nl] OSM GPSen merken
Danny Maas wrote: Hoe staat het inmiddels met de kaartstukken voor de Garmins met kleinere geheugens? Wat bedoel je precies? Als je de kaarten op http://garmin.na1400.info bedoeld, dan moet je http://tile.openstreetmap.nl/~lambertus/garmin/nl-tinymaps.zip hebben. Download deze en kopieer de interessante delen op de GPS. Helaas heb ik op dit moment geen eenvoudig lijstje waarop aangegeven is hoe de kaartnummers verdeeld zijn over Nederland maar de verdeling is als volgt: - lage kaartnummers = west Nederland - hoge kaartnummer = oost Nederland Op basis hiervan je kunt de kaarten in Explorer selecteren totdat je er 24MB hebt en deze op de micro-SD kaart kopieren. (Note to self: Maak vanavond een kaart installer voor MapSource) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] NL tileserver update
Lambertus wrote: Martijn van Oosterhout wrote: 2008/1/21 Lambertus [EMAIL PROTECTED]: De layer staat in de permalink maar als ik de permalink in een nieuw browser window stop laadt de verkeerde (default?) layer. Hmm, en nu? Ok, de permalink werkt nu goed. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] NL tileserver update
Martijn van Oosterhout wrote: 2008/1/21 Lambertus [EMAIL PROTECTED]: De layer staat in de permalink maar als ik de permalink in een nieuw browser window stop laadt de verkeerde (default?) layer. Hmm, en nu? Ha, ik probeer het maar de tileserver is zo druk met HTTPD en Postmaster processen dat het laden van de kaart nu al minuten duurt. Zelfs inloggen met SSH duurde erg lang. De tileserver is zeker bezig met het opnieuw genereren van tiles... Kom maar op met die dedicated machine! Ik probeer het zo nog eens... ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-talk-be] Subsidie NLNet
Ha, Dat doen we al (tile.openstreetmap.nl) maar dat wist je al denk ik - jij bent toch ook actief op talk-nl. Ik forward even naar talk-nl, daar kunnen we erover discussieren. Martijn 2008/1/22, Jo [EMAIL PROTECTED]: Martijn, Ik heb een vraagje. Als jullie Nederland gaan renderen met een aparte server. Zou het dan mogelijk zijn om België er ook bij te nemen? De oppervlakte verdubbelt dan wel bijna, maar hier in België is natuurlijk nog niet zoveel data, dus waarschijnlijk stelt het niet zoveel voor. Polyglot ___ Talk-be mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-be -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.handsomedevil.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-talk-be] Subsidie NLNet
Zoals ik met zoveel dingen zeg: ik vind het goed, maar ik weet niet of dit de bedoeling is... (Mij kan niet wachten tot de meeting in Februari). Qua data is het niks... De load wordt bepaald door het aantal gebruikers, niet door de hoeveelheid data. Mvg, On Jan 22, 2008 11:28 AM, Martijn van Exel [EMAIL PROTECTED] wrote: Ha, Dat doen we al (tile.openstreetmap.nl) maar dat wist je al denk ik - jij bent toch ook actief op talk-nl. Ik forward even naar talk-nl, daar kunnen we erover discussieren. Martijn 2008/1/22, Jo [EMAIL PROTECTED]: Martijn, Ik heb een vraagje. Als jullie Nederland gaan renderen met een aparte server. Zou het dan mogelijk zijn om België er ook bij te nemen? De oppervlakte verdubbelt dan wel bijna, maar hier in België is natuurlijk nog niet zoveel data, dus waarschijnlijk stelt het niet zoveel voor. Polyglot ___ Talk-be mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-be -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.handsomedevil.nl/ ___ 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] Hulp bij tileserver (apache2)
Op het ogenblik worden de tiles niet door de client gecached, what nogal onefficient is. Ik wil eigenlijk dat ze minstens 1 uur gecached worden, maar als ik: ExpiresDefault A300 of sort gelijke doe, verandert niks. Heeft iemend misschien een idee? Mvg, -- 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
Re: [OSM-talk-nl] Hulp bij tileserver (apache2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Martijn van Oosterhout schreef: Op het ogenblik worden de tiles niet door de client gecached, what nogal onefficient is. Ik wil eigenlijk dat ze minstens 1 uur gecached worden, maar als ik: ExpiresDefault A300 of sort gelijke doe, verandert niks. Heeft iemend misschien een idee? Moet die tileserver alleen plaatjes serveren? Of ook nog wat CGI werk? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHlhQEYH1+F2Rqwn0RCuw6AJoD8hd5McPkbvlQM4SOaLIGwGOzMACfWeu0 9ZQayU0U1JqfzL9XiaP6sY0= =cccL -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Hulp bij tileserver (apache2)
2008/1/22 Stefan de Konink [EMAIL PROTECTED]: Martijn van Oosterhout schreef: Op het ogenblik worden de tiles niet door de client gecached, what nogal onefficient is. Ik wil eigenlijk dat ze minstens 1 uur gecached worden, maar als ik: ExpiresDefault A300 of sort gelijke doe, verandert niks. Heeft iemend misschien een idee? Moet die tileserver alleen plaatjes serveren? Of ook nog wat CGI werk? Het is allemaal CGI... De vraag is of ik dit in apache kan installen. Mvg, -- 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] Installer voor Garmin kaarten
Ik heb een installer gemaakt/geconfigureerd die de Garmin OpenStreetMap kaarten kan installeren onder MapSource. Dit betekend dat de kaarten geinstalleerd kunnen worden zonder dat je zelf hoeft te knutselen met het register van Windows. Een hele vooruitgang, vooral voor eindgebruikers zonder veel Windows kennis. Het is een eerste versie maar bij werkt het wel. Her en der kloppen wat teksten niet helemaal en ik heb nog een hele waslijst aan wensen en verbeteringen. Ik hoop dat er wat mensen zijn die de installer willen uitproberen en feedback/wensen geven. Veel plezier ermee. De directe (maar wellicht tijdelijke) download locatie: http://tile.openstreetmap.nl/~lambertus/garmin/OpenStreetMap_Garmin_maps_(NL).exe In de toekomst bied ik deze download aan via: http://garmin.na1400.info ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Hulp bij tileserver (apache2)
Peter Peterse schreef: Martijn van Oosterhout schreef: Op het ogenblik worden de tiles niet door de client gecached, what nogal onefficient is. Ik wil eigenlijk dat ze minstens 1 uur gecached worden, maar als ik: ExpiresDefault A300 of sort gelijke doe, verandert niks. Heeft iemend misschien een idee? Mvg, Hallo Martijn, heb je deze setting meegenomen: |ExpiresActive On| En is de module mod_exp geladen? Succes. Peter Het is natuurlijk de module mod_expires Peter ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Hulp bij tileserver (apache2)
2008/1/22 Peter Peterse [EMAIL PROTECTED]: heb je deze setting meegenomen: |ExpiresActive On| Dat was het, ik wist dat ik iets over het hoofd had gezien... Bedankt! Mvg, -- 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
Re: [OSM-talk-nl] Tileserver op Nederkaartblog
Volgens mij hadden we inderdaad 12 uur afgesproken. Ik ga met de auto vanuit Amsterdam, had al een halve afspraak met Martijn vO om hem op te halen in Utrecht, Martijn P, jij kan ntrlk ook meerijden als je wilt. Martijn vE (ik zie het al voor mij: 3 martijns in een 205. Hahaha) Op 22 jan 2008, om 23:20 heeft Martijn van Oosterhout het volgende geschreven: On Jan 22, 2008 10:26 PM, Martijn Pannevis [EMAIL PROTECTED] wrote: Ik neem, gezien de lijst op Doodle aan, dat het de 16e feb wordt? Gezien de 2 uur reistijd uit Amsterdam zou ik iets meer voor bijvoorbeeld begin van de middag zijn. Groeten, Martijn Pannevis. Laste dat ik hoorde was het 12uur, klopt dat? Mvg, -- 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: [Talk-de] Potlach! *kotz*
Frederik Ramm [EMAIL PROTECTED] wrote: Davon, jetzt erstmal auf die Bremse zu treten und sich vernuenftige Software zu ueberlegen, halte ich wenig. Bis wir uns auf vernuenftige Software geeinigt haben, ist das Projekt tot ;-) Das sehe ich auch so. Wenn gescheite Software [tm] da ist kann man die Daten immer noch in deren Format konvertieren... Sven -- Why are there so many Unix-haters-handbooks and not even one Microsoft-Windows-haters handbook? Gurer vf ab arrq sbe n unaqobbx gb ungr Zvpebfbsg Jvaqbjf! /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] Potlach! *kotz*
Hallo, Das kann man doch ueberhaupt nicht vergleichen. OSM ist ein Crowdsourcing-Projekt. Da kommt es nicht auf einzelne Entwickler an, sondern auf die Masse von Mitmachern, von denen jeder nur ein kleines bisschen zum Erfolg beitraegt. So wie eben die Wikipedia auch; da gibt es zwar einen harten Kern von Aktiven, aber ohne die Massen von Leuten, die da mitmachen, koennten die nichts erreichen. Wenn schon der Vergleich mit KDE hinken soll, hinkt der Vergleich mit Wikipedia noch viel mehr. Wikipedia ist eine Ansammlung von Texten und Bildern, die schwach miteinander verknüpft sind. Eine Straßenkarte ist ein straffes mathematisch abgesichertes Gebilde. Kommt eben drauf an, was man will. Ein GIS, das die Daten nur schwach verknüpft kann man so aufziehen, aber solange eine digitale Karte eine ziemlich zentrale Rolle hat, gibts sehr strenge Regeln. Der kürzeste Weg von X nach Y ist eine exakte Lösung einer exakten Problemstellung und wenn OSM was anderes ausgibt, arbeiet OSM fehlerhaft. Wenn die Daten erstmal da sind, dann kommen die Anwendungsprogram- mierer ganz von allein. Nö, das sollte Hand in Hand gehen. Erst ein schoenes Korsett aufbauen und das dann von willigen Arbeitsbienen nach Vorschrift befuellen lassen, das geht halt (hier) nicht. Warum diese Panik vor einem angeblichen Korsett um das es hier gar nicht geht? Es geht nach wie vor darum, das Erarbeitete zu dokumentieren und zu schützen und nicht darum ein Korsett in den leeren Raum zu stellen. Die Programmierer, die wir brauchen, tun sich nicht durch perfekte Algorithmen und coole Optimierungen hervor, sondern dadurch, dass sie mit Crowdsourcing angemessen umgehen koennen. Hier sind keine Elfenbeinturmbastler gefragt, die nur mit idealen Bedingungen und punktfoermigen Massen rechnen koennen. Siehe oben: es gibt falsch und richtig. Wenn mich das Navi auffordert, gegen die Fahrtrichtung in die Einbahnstraße abzubiegen, hat das Navi (im KFZ-Modus) einen Fehler gemacht, da gibts nichts dran zu deuteln. Egal, ob Crowdsourcingprogger oder Elfenbeinspezialist - diese Randbedingung steht. Erwarte ich deshalb, dass alle OSM-Daten von Anfang an perfekt sind und tolles Routing ermöglichen? Natürlich nicht. Aber was ich schon gerne sehen würde, ist ein Weg dorthin und genau der fehlt mir. Derzeit wird alles immer noch chaotischer und undurchsichtiger und alles was in Richtung Qualitätssicherung und Anwender-API geht, wird abgewürgt. Wer fuer OSM gute Software machen will, der muss mit unvollstaendigen, falschen, schmutzigen, unvorhergesehen strukturierten Daten umgehen koennen. Das ist eine ganz andere Welt als bei der kommerziellen Konkurrenz, wo von oben festgelegt wird, wie's gemacht wird, und dann faehrt der Video-Van los... Und genau das ist eine unmögliche Forderung. Da kannst du genauso von den Leuten erwarten, dass sie C-Programme schreiben, die mit einem Pointer, der irgendwo hinzeigt, bitte etwas sinnvolles machen sollen. Ein falscher Wert, der einen falschen Graphen erzeugt, erzeugt ein falsches Ergebnis - so einfach ist das. Und die Attributsebene? Ich kann schon ein Programm schreiben das 100erte von ähnlichen Beschreibungen eines Werts filtert und irgendwie interpretiert. Dann habe ich aber mit viel Aufwand etwas erreicht, das immer noch viel ungenauer ist als ein popliger Zahlenwert, der mit einer genauen Definition verbunden ist. Damit soll man Anwendungsentwickler anlocken? Schau Dir doch mal das MediaWiki an und was das (software-design- maessig) fuer ein Haufen Schrott ist. Hat die Wikipedia aber bis jetzt nicht zu Fall gebracht. Davon, jetzt erstmal auf die Bremse zu treten und sich vernuenftige Software zu ueberlegen, halte ich wenig. Bis wir uns auf vernuenftige Software geeinigt haben, ist das Projekt tot ;-) Wer will denn auf die Bremse treten, davon war nie die Rede. Man sollte sich nur vielleicht überlegen ob es Beschleunigung um jeden Preis sein muss. Derzeit ist dieser Preis, dass die vorhandene Datenbasis verunstaltet wird. Da das Projekt mich als Elfenbeinturmentwickler nach deiner Aussage nicht brauchen kann, mach ich inzwischen mit den nativen AND-Daten weiter und hab mir einen schnellen Einlesefilter dafür geschrieben. Deren Shapeformat ist wirklich alles andere als schön, hat aber einen Vorteil - es ist sauber dokumentiert und kann alles, was man fürs Routing braucht. Ich mag lieber coole schnelle Algorithmen machen, statt ein 'wie taggen wir denn heute'- Schätzeisen. In diesem Sinne - Danke ans OSM-Projekt für die AND-Daten und als Tagger stehe ich weiterhin zur Verfügung. Grüsse Hubert -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Erster OpenGeoDB Import in OpenStreetMap ist durchgelaufen.
Friedhelm Schmidt wrote: Also, ich bin überhaupt nicht begeistert. Die importierten Daten sind weder vollständig noch korrekt. In meiner Gegend rund um Heilbronn sind kaum Orte hinzugekommen, aber mindestens 30% der bestehenden wurden dupliziert. Hallo Friedhelm, kannst du bitte mal in der opengeodb selbst nachprüfen, wie unvollständig die Daten sind? http://fa-technik.adfc.de/code/opengeodb.pl?locid=584;c=DE;distance=15 bringt schon mehr als hundert Treffer. Kann es sein, dass der Landkreis Heilbronn tatsächlich mehr als 1000 km^2 umfasst? Bei den Duplizierten sieht man schön, dass zum Teil die Koordinaten recht kreativ sind. Oder liegt Löwenstein neuerdings im Tal? Ist 49.09940 / 9.38139 so weit daneben? Typischerweise sind die Abweichungen eher größer, weil die Rohdaten nur mit einer Genauigkeit auf Zehntelminuten vorlagen. Wie ich lese, geht es vielen anderen Mappern ähnlich. Vielleicht sollte man in Zukunft einen lokal begrenzten Probelauf machen und anhand des Resultats 'rumfragen ob ein Import sinnvoll und gewünscht ist. Für mich kam die Aktion auch etwas überraschend - ein Probelauf in einem kleineren Gebiet wäre kein Fehler gewesen. Im Moment weiss ich nicht, wann Sven hier mit dem letzten, erheblich besserten Dump ein update vornehmen wird. Er hatte hier zwar um aktuellere Daten gebeten. Die Lizenzproblematik von OSM hatte das aber leider blockiert. Demzufolge wich er auf alte, fehlerhafte Daten aus. Mit dem aktuellen Dump dürften ein paar neue Fehler hinzukommen, insgesamt aber auch die von dir gewünschte Anzahl an Orten bei Heilbronn hinzugewinnen. Meine Empfehlung für ein Update: - Abgleich passender Namen nicht über die lange Schreibweise von opengeodb, sondern über die kurze Schreibweise, die als sortname (ASCII) in der opengeodb vorliegt - Beschränkung auf die Ebenen 6 (Gemeinden), 7 (Orte), 8 (Ortsteile) Löwenstein würde dabei dennoch doppelt erscheinen, einerseits als Gemeinde, andererseits als eine der Ortschaften/Ortsteile: http://fa-technik.adfc.de/code/opengeodb.pl?parts=20354;c=DE 82642 Gerberhäusle 49.1000 / 9.3833 82643 Hirrweiler49.0931 / 9.4089 82644 Hößlinsülz49.1167 / 9.3667 82645 Lichtenstern 49.1000 / 9.4000 81304 Löwenstein49.0994 / 9.3814 81305 Reisach 49.1078 / 9.3981 82646 Rittelhof 49.1019 / 9.3706 82647 Teusserbad49.0833 / 9.3833 Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Schweizer Grenzen
Halli Hallo, Das Schweizerische Bundesamt für Statistik (nicht swisstopo) hat frei verfügbare ShapeFiles der Schweizer Gemeinde-, Bezirks-, Kantons- und Staatsgrenzen. http://www.bfs.admin.ch/bfs/portal/de/index/dienstleistungen/geostat/datenbeschreibung/generalisierte_gemeindegrenzen.html Unkommerzielle Verwendung unter Angabe der Quelle ist erlaubt. Komerzielle Nutzer müssen nachfragen. Hat jemand Lust abzuklären wie sich das mit einer cc-by-sa-2.0 Lizenz verträgt? Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Automaten Tag
Jens schrieb: Machst du? Ich kenne das noch nicht. Jens Hmm, mir fehlen irgendwie die Englischkenntnisse dazu. Im Prinzip muss man halt auf http://wiki.openstreetmap.org/index.php/Proposed_features nen entsprechenden Eintrag dazu anlegen. Mehr steht auf der Seite. MfG ah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Erster OpenGeoDB Import in OpenStreetMap ist durchgelaufen.
Martin Trautmann schrieb: - Beschränkung auf die Ebenen 6 (Gemeinden), 7 (Orte), 8 (Ortsteile) Löwenstein würde dabei dennoch doppelt erscheinen, einerseits als Gemeinde, andererseits als eine der Ortschaften/Ortsteile: Bei dem denkst du momentan noch irgendwie falsch, Martin. Alles was sich nicht als Punkt in OSM darstellen lässt, sollte nur als Relation importiert werden. Um ein Beispiel bei mir in der Gegend zu bringen: Die Gemeinde Mönchsdeggingen besteht aus folgenden Orten: Mönchsdeggingen, Untermagerbein, Merzingen, Rohrbach, Schaffhausen, Ziswingen. Momentan ist der Ort Mönchsdeggingen in OSM als Node mit ogdb:type=Gemeinde vorhanden, die anderen Orte verweisen mit ihrem is_in Tag auf diesen Node. Richtig wäre eigendlich eine Relation Mönchsdeggingen anzulegen, zu auf die dann die einzelnen Orte verweisen. Das selbe gilt für Kreisfreie Städte und die ganzen anderen Fälle in denen es momentan noch zwei Nodes mit unterschiedlichen ogdb:type Tags gibt. MfG Andi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Relation Editor in JOSM
Hi, wie weit kann man JOSM eigendlich momentan Relations bearbeiten? Ist das soweit schon alles fertig? inbesondere @ Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Relation Editor in JOSM
wie weit kann man JOSM eigendlich momentan Relations bearbeiten? Ist das soweit schon alles fertig? inbesondere @ Frederik Das geht schon seit ner ganzen Weile recht gut. Diverse Wälder mit Löchern und Seen mit Inseln zeugen davon :) Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Wälder besser abzeichnen mit IR-Bilder n
Hallo, ich weiß nicht, ob das schon jemand entdeckt hat, aber über das Landsat-WMS (z.B. per JOSM-Plugin) kann man auch Bilder aus dem Infrarot-Spektrum beziehen. Der Vorteil: Wälder sind schön dunkel eingefärbt, heben sich von umliegenden Wiesen und Äckern sehr gut ab und lassen sich somit wesentlich besser abpinseln. Einrichtung: Im Konfigurationspanel des WMS-Plugins in JOSM einen neuen Eintrag z.B. namens Landsat IR anlegen und folgende URL eintragen: http://onearth.jpl.nasa.gov/wms.cgi?request=GetMaplayers=global_mosaic_basestyles=IR3srs=EPSG:4326format=image/jpeg Ein Neustart des Programms ist nicht erforderlich. Gruß, Wabba ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wälder besser abzeichnen mit IR-Bilder n
Daniel Schmidt schrieb: Hallo, ich weiß nicht, ob das schon jemand entdeckt hat, aber über das Landsat-WMS (z.B. per JOSM-Plugin) kann man auch Bilder aus dem Infrarot-Spektrum beziehen. Gruß, Wabba Mhh... ich habe zwar von dem Layer gewusst, aber auf die Idee, ihn in JOSM zu laden, bin ich noch nicht gekommen, danke für den grandiosen Tipp. Der IR-Layer ist auch recht gut dafür, kleine Flüsse und Bäche zu finden, wenn man grob weiß, wie sie laufen aber man sie auf dem normalen Landsat-Bild nicht sieht. Jannis 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] Erster OpenGeoDB Import in OpenStreetMap ist durchgelaufen.
Andreas Hubel wrote: Martin Trautmann schrieb: - Beschränkung auf die Ebenen 6 (Gemeinden), 7 (Orte), 8 (Ortsteile) Löwenstein würde dabei dennoch doppelt erscheinen, einerseits als Gemeinde, andererseits als eine der Ortschaften/Ortsteile: Bei dem denkst du momentan noch irgendwie falsch, Martin. Alles was sich nicht als Punkt in OSM darstellen lässt, sollte nur als Relation importiert werden. Hallo Andreas, wie die Daten zu importieren sind, das kann ich nicht beurteilen und beeinflussen - ich beschreibe nur, wie die Daten in der opengeodb organisiert sind. Dort wird mit genau solchen Relationen gearbeitet, wie du sie wünschst. Um ein Beispiel bei mir in der Gegend zu bringen: Die Gemeinde Mönchsdeggingen besteht aus folgenden Orten: Mönchsdeggingen, Untermagerbein, Merzingen, Rohrbach, Schaffhausen, Ziswingen. Momentan ist der Ort Mönchsdeggingen in OSM als Node mit ogdb:type=Gemeinde vorhanden, die anderen Orte verweisen mit ihrem is_in Tag auf diesen Node. Richtig wäre eigendlich eine Relation Mönchsdeggingen anzulegen, zu auf die dann die einzelnen Orte verweisen. Wenn der Punkt von Mönchsdeggingen den Ort bezeichnet, dann sollte der wohl am ehestem als Ort oder Ortschaft markiert werden. Er und alle anderen Orte der Gemeinde sollten dann verweisen auf die Gemeinde Mönchsdeggingen. Es ist grundsätzlich problematisch, eine Fläche nur durch einen Punkt zu markieren. Der Mittelpunkt der Ortschaft Mönchsdeggingen liegt vermutlich an anderer Stelle als der Mittelpunkt der Gemeinde Mönchsdeggingen - und eine Möglichkeit, die Gemeindekoordinaten festzulegen, ist ein solcher Mittelpunkt (Umkreis, Schwerpunkt usw.) Eine andere Möglichkeit ist natürlich, die Koordinate auf die Gemeindeverwaltung zu legen - dann würden Punkte für Ort und Gemeinde direkt übereinander liegen. Für den Import besser wäre vielleicht, bei Duplikaten auf Orts- und Gemeindeebene die Gemeinde zu übergehen und nur den Ort mit opengeodb-Daten zu übernehmen. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wälder besser abzeichnen mit IR-Bilder n
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Interessant währen auch Fehlfarben Komposite z.B. mit Landsat kanal 4,3,2 auf den RGB Kanälen damit könnte man verschiedene Bereiche auch sehr gut optisch trennen. oder auch NDVI Bilder. NDVI gitb es habe es aber gerade auf die schnelle nicht in JOSM bekommen. Grüße Fabian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (MingW32) Comment: GnuPT 2.9.1 iD8DBQFHljVf8pTXCZH6O18RApZfAKD+Xg2JybgXj+iULiGQ3XTP5zwxfwCg7xd2 1IQ3iguNCxVyYLsWts4v1NU= =mNFP -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Potlach! *kotz*
Frederik Ramm schrieb: Wer fuer OSM gute Software machen will, der muss mit unvollstaendigen, falschen, schmutzigen, unvorhergesehen strukturierten Daten umgehen koennen. Das ist eine ganz andere Welt als bei der kommerziellen Konkurrenz, wo von oben festgelegt wird, wie's gemacht wird, und dann faehrt der Video-Van los.. Nichts desto trotz halte ich von freien Tags nicht viel, man sollte sich auf einen gemeinsamen Standart einigen und diesen auch verpflichtend einführen. Freie Software hin und her, aber nachdem die Daten ja nicht nur zum Scherze da sind, sondern später evtl. auch mal in Navis und was weiss ich verwendet werden sollen, müssen auch alle Wege gleich getaggt sein und nicht so, dass jeder Mapper einen eigenen Schlüssel einführt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Potlach! *kotz*
Joerg Fischer schrieb: Ich würde mir das gerne mal mit der History Funktion von http://crschmidt.net/osm/osm.html?zoom=0lat=49.77483lon=10.02944layers=BT anschauen Hab ich mir gerade angesehen, ich (oder mein Firefox?) kann das nicht bedienen. Ich seh nur die Dinge, die ich direkt in openstreetmap.org auch sehe. Du musst den Link Download current view bennutzen, dann läd er sich die aktuellen Daten über die API runter und stellt die dar. In deinem letzen Fall http://crschmidt.net/osm/osm.html?lat=50.7451lon=12.9933zoom=10layers=B0FT sieht man z.B. das die Primary durch den Ort momentan fehlt. Die History erreicht man wenn man eine Straße anklickt und dann auf Edit und dort dann auf History klickt. Für einen Node der gelöschten Straße wäre das z.B.: http://crschmidt.net/osm/history.html?type=nodeid=27341389 Für Wege wäre das http://crschmidt.net/osm/history.html?type=wayid=22419114 Falls du also die Id des weges noch hast kannst du nachschauen, wer den gelöscht hat. Man musste das JS das die OSM Daten vom Server läd, entsprechend anpassen, das es auch die historischen anzeigt. MfG Andi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Schweizer Grenzen
Sali zämme, OK, das sind trotzdem stark generaliserte Datensätze, immeherin besser als nicht. F. Ramm hatte schon einmal dem BFS geschrieben, im Zusammenhang mit dem Erstellen des Mini-planet für die Schweiz (clipping): Meinst Du die, die man fuer 90 Fr. als offene Datei kaufen kann, oder bieten die auch was kostenloses an? Ich koennte ja mal hinschreiben. Und die Antwort: Sie sagen das hier: Wenn ich Sie richtig verstehe, benutzen Sie unsere Landes- oder Kantonsgrenzen (Generalisierungsstufe 3) als Clipcover um die Strassendaten auszuschneiden. Im Endprodukt werden weder die Grenzen als Ganzes noch Teile davon weitergegeben. Wenn dieser Sachverhalt zutrifft wird dies nach unseren nicht so strengen Massstäben nicht als 'kommerzielle Nutzung' betrachtet und ist somit nicht Bewilligungspflichtig. Als einzige Freie Datensatz gibt das (OK, eher witzig): http://schaer.freeflux.net/blog/archive/2007/03/14/gemeindegrenzen- der-schweiz.html Viele Grüsse Marc Le 22 janv. 08 à 13:59, Raphael Studer a écrit : Halli Hallo, Das Schweizerische Bundesamt für Statistik (nicht swisstopo) hat frei verfügbare ShapeFiles der Schweizer Gemeinde-, Bezirks-, Kantons- und Staatsgrenzen. http://www.bfs.admin.ch/bfs/portal/de/index/dienstleistungen/ geostat/datenbeschreibung/generalisierte_gemeindegrenzen.html Unkommerzielle Verwendung unter Angabe der Quelle ist erlaubt. Komerzielle Nutzer müssen nachfragen. Hat jemand Lust abzuklären wie sich das mit einer cc-by-sa-2.0 Lizenz verträgt? Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wälder besser abzeichnen mit IR-Bildern
Moin, On Tue, 22 Jan 2008 15:57:57 +0100 Daniel Schmidt [EMAIL PROTECTED] wrote: Hallo, ich weiß nicht, ob das schon jemand entdeckt hat, aber über das Landsat-WMS (z.B. per JOSM-Plugin) kann man auch Bilder aus dem Infrarot-Spektrum beziehen. Der Vorteil: Wälder sind schön dunkel eingefärbt, heben sich von umliegenden Wiesen und Äckern sehr gut ab und lassen sich somit wesentlich besser abpinseln. hmmm, also in meiner Gegend erscheinen Flüsse irgendwie doppelt, das sieht so aus, als wenn man zweimal das gleiche Bild irgendwie verschoben aufeinanderlegt. also nicht wirklich brauchbar. MfG Andreas Kemnade ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Potlach! *kotz*
André Reichelt [EMAIL PROTECTED] writes: Frederik Ramm schrieb: muss mit unvollstaendigen, falschen, schmutzigen, unvorhergesehen strukturierten Daten umgehen koennen. Standart 'nuff said. Cheers Colin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Betr.: Anonymes Editieren
mallok schrieb: Ui! Und gibt es irgendwo einen Hinweis darauf, in welchen Laendern GPS mapping verboten ist? mallok -Ursprüngliche Nachricht Es gibt Laender gibt, in denen GPS-Mappen unter Knast-Androhung verboten ist (China, China ist ein echtes Thema! Kenne das von Bekannten, welche in der Navi-Branche beschäftigt sind...:-( MfG Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Relation Editor in JOSM
Hallo, wie weit kann man JOSM eigendlich momentan Relations bearbeiten? Ist das soweit schon alles fertig? inbesondere @ Frederik JOSM hat einen generischen Relation-Editor, mit dem Du alles machen kannst, also beliebige Relations mit beliebigen Members und beliebigen Tags aufstellen. Allerings laesst der, besonders fuer Alltagsfaelle, etwas Komfort vermissen, und es gibt, wie im Rahmen des OpenGeoDB-Imports rauskam, einen Bug beim Hochladen von Relations, die Relations enthalten (hier ist nicht sichergestellt, dass die referenzierten Relations vor den referenzierenden hochgeladen werden). Ich plane/erhoffe mir fuer die Zukunft, dass wir kofortablere Editiermoeglichkeiten fuer haeufige Relations haben, eventuell sogar dahingehend, dass dem Durchschnittsuser gar nicht mehr angezeigt wird, dass er eine Relation bearbeitet, sondern ein Abbiegeverbot usw. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Schweizer Grenzen
OK, das sind trotzdem stark generaliserte Datensätze, immeherin besser als nicht. Sie sind jedenfalls besser als die Kantonsgrenzen die wir bis jetzt auf Out-of-Date Maps gefunden haben. F. Ramm hatte schon einmal dem BFS geschrieben, im Zusammenhang mit dem Erstellen des Mini-planet für die Schweiz (clipping): Meinst Du die, die man fuer 90 Fr. als offene Datei kaufen kann, oder bieten die auch was kostenloses an? Ich koennte ja mal hinschreiben. Sie sagen das hier: Wenn ich Sie richtig verstehe, benutzen Sie unsere Landes- oder Kantonsgrenzen (Generalisierungsstufe 3) als Clipcover um die Strassendaten auszuschneiden. Im Endprodukt werden weder die Grenzen als Ganzes noch Teile davon weitergegeben. Wenn dieser Sachverhalt zutrifft wird dies nach unseren nicht so strengen Massstäben nicht als 'kommerzielle Nutzung' betrachtet und ist somit nicht Bewilligungspflichtig. In diesem Fall würden wir die Daten ja nicht mehr nur zum clippen verwenden sondern wirklich als Grenzen ablegen. Natürlich ist es noch immer keine Kommerzielle nutzung und wäre vielleicht auch nicht Bewilligungspflichtig. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [OSM-talk-fr] Evolution vers les chemins de randon née
highway=footway pour les sentiers et highway=track si assez large pour un 4x4 Pour les routes forestieres interdites aux vehicules de tourisme, ajouter un tag d'access, genre motorcar= no + motorcycle=no Pour taguer la reference, j'y ai aussi réfléchis pour les Vosges. On pourrait imaginer un ref dédié pour le GR, genre gr_ref=GR10 ou gr_ref=10 . Mais pour les circuits de rando au niveau régional, je ne connais pas les références mais ce que tout le monde peut voir, ce sont les balises. Or je viens de voir sur internet que les balises du GR sont déposés comme des marques (ainsi que le terme GR). Je ne pense pas que taguer les ref GR posent un problème de droit (encore que) mais je suis moins sûr pour les balises. De plus, OSM ne propose pour l'instant aucune solution standard pour les balises de rando mais rien n'empeche quelqu'un de modifier un des logiciels de rendus pour l'adapter a ce genre de cartes (il y a une carte en ligne dédiée aux pistes cyclables par exemple). Mais il y a un problème de droits d'auteur à régler : dans les Vosges, les balises sont posées et entrenues par le Club vosgien qui publie ses propres cartes en partenariat avec l'IGN. C'est pour eux une importante source de revenues et je ne pense pas qu'ils vont lâcher la poule aux oeufs d'or aussi facilement. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
[OSM-talk-fr] couper un segment sous JOSM
Bonjour, j'ai parfois besoin de rajouter un node au milieu d'un segment. Je voulais savoir si cela était possible avec JOSM. Si oui, comment ? Merci, Axel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] couper un segment sous JOSM
Bonjour, Il suffit de s'assurer de n'avoir aucun node sélectionné, de prendre l'outil de création de node/ways (raccourcis clavier s) et de cliquer au milieu du way. On Jan 22, 2008 12:05 PM, Axel R. [EMAIL PROTECTED] wrote: Bonjour, j'ai parfois besoin de rajouter un node au milieu d'un segment. Je voulais savoir si cela était possible avec JOSM. Si oui, comment ? Merci, Axel ___ 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] couper un segment sous JOSM
Bonjour, Il me semble que le racourci s c'est pour selectionner. Le racourci de création de node est a. Faut il que le way soit selectionné ou que rien ne soit selectionné ? Merci, Axel Bonjour, Il suffit de s'assurer de n'avoir aucun node sélectionné, de prendre l'outil de création de node/ways (raccourcis clavier s) et de cliquer au milieu du way. On Jan 22, 2008 12:05 PM, Axel R. [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Bonjour, j'ai parfois besoin de rajouter un node au milieu d'un segment. Je voulais savoir si cela était possible avec JOSM. Si oui, comment ? Merci, Axel ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr 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] couper un segment sous JOSM
Chez moi c'est n pour rajouter un noeud :) Le 22/01/08, Axel R.[EMAIL PROTECTED] a écrit : Bonjour, Il me semble que le racourci s c'est pour selectionner. Le racourci de création de node est a. Faut il que le way soit selectionné ou que rien ne soit selectionné ? Merci, Axel Bonjour, Il suffit de s'assurer de n'avoir aucun node sélectionné, de prendre l'outil de création de node/ways (raccourcis clavier s) et de cliquer au milieu du way. On Jan 22, 2008 12:05 PM, Axel R. [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Bonjour, j'ai parfois besoin de rajouter un node au milieu d'un segment. Je voulais savoir si cela était possible avec JOSM. Si oui, comment ? Merci, Axel ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr 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] Evolution vers les chemins de randon née
tu as l'url de cette carte dédiée aux pistes cyclables ? C'est sur le wiki : http://wiki.openstreetmap.org/index.php/Cycle_layer et ça renvoie sur le site http://www.gravitystorm.co.uk/osm/ C'était limité à l'Angleterre au départ mais il semble l'avoir étendu (au moins à l'Europe) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Que faire des routes qui ne correspo ndent pas à la carte Yahoo?
attention, j'ai déjà lu plusieurs réponses sur ce sujet dans les threads en anglais : les images Yahoo! ne sont pas une projection corrigée et peuvent avoir une dérive importante par rapport à la réalité (j'ai lu jusqu'à une centaine de mètres, mais l'exemple indiqué ci-dessus est troublant) surtout si la zone n'est pas couverte en haute résolution. Il faut toujours faire plus confiance aux relevés GPS qu'aux images Yahoo!. Une exception toutefois: en ville, avec l'effet canyon, le GPS aura éventuellement un moins bon résultat qu'une image haute résolution de Yahoo Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Evolution vers les chemins de randon née
Pieren Pieren a écrit : tu as l'url de cette carte dédiée aux pistes cyclables ? C'est sur le wiki : http://wiki.openstreetmap.org/index.php/Cycle_layer et ça renvoie sur le site http://www.gravitystorm.co.uk/osm/ C'était limité à l'Angleterre au départ mais il semble l'avoir étendu (au moins à l'Europe) Pour ma part, je n'arrive pas à zoomer sur la france... :-( Axel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Evolution vers les chemins de randonn ée
Pour ma part, je n'arrive pas à zoomer sur la france... :-( Peut-être utilisent-ils des tag spéciaux pour leur routes ? Ce ne serait pas parce que le moteur de rendu des cartes ne calcule (et garde) les images QUE si la carte a été visualisée récemment ? En tout cas on voit bien la limite d'affichage de la carte quand on zoom sur Amiens, la France semble filtrée ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Evolution vers les chemins de randonn ée
sylvain letuffe wrote: Bonjour à tous ! Je me présente : tout nouveau contributeur sur osm, je vie à chambéry (Savoie) pour laquelle je commence le mapping des rues et diverses routes à l'entour. je suis a grenoble. on peut se voir quand tu veux :-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
