Re: [Talk-transit] NaPTAN import starts - Birmingham trial area first
In message 49d135f1.9010...@00l.de Gerrit Lammert o...@00l.de wrote: Hi. I'm exited to see how this works out. Beeing curious, I just zoomed in into Birmingham and noticed two things: 1) Imported stops seem to be close to the already mapped ones but off by some meters 2) Some Streets seem to consist entirely of bus_stops. (http://www.openstreetmap.org/?lat=52.479838lon=-1.896227zoom=18lay ers=B000FTF) Is this real?? Yes it is -- Peter J Stoner UK Regional Coordinator Traveline www.travelinedata.org.uk a trading name of Intelligent Travel Solutions Ltd company number 3826797 Drury House, 34-43 Russell Street, LONDON WC2B 5HA ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] [Talk-gb-westmidlands] Naptan alignment
On 31 Mar 2009, at 13:23, Andy Robinson (blackadder-lists) wrote: I've already started correcting data like this. I too have noted that some stops are not correctly positioned in relation to the road they are on. Where we only have a single trace along a road they could be correct but the ones I looked at last night where we have plenty of traces (main road) were in some cases either too far back or too close to the centreline of the road. I also fond some possible referencing errors for bus stop pairs on either side of the road but need to resurvey as a double check. As of my mapping session this morning I'm taking my bike right up to the stop and taking the photo from directly under the sign. That should help see what sort of positional errors exist in the data. The only problem is that I'm mapping Walsall and so need more imported data before I'll know ;-) Import looks good. A few points: 1) The bearing is useful to ensure that the stop is put on the correct side of the street) . Normally the stop will already be on the correct side using the lat-long, but if the stop in misplaced by poor GPS then we could place it on the wrong side. I did find one that was on the wrong side of the street in the OSM environment using the bearing from the official data. 2) Some Naptan records seem to be missing in OSM. In the case where there is already a bus stop in the right place is the Naptan record just being deleted in the review pass? If so then important data for maintenance is being lost. I would suggest that the two records are merged to ensure that there are NaPTAN codes for every stop. 3) I find it interesting that in some places OSM has bus stops that are not in NaPTAN, that might be because they have been removed recently or be an omission in NaPTAN. 4) I notice that sometimes the NaPTAN stop and the OSM one are some significant distance apart which begs the question about which one is right. Anyway, it looks like the detective work is now starts! Great work. Regards, Cheers Andy -Original Message- From: talk-gb-westmidlands-boun...@openstreetmap.org [mailto:talk-gb- westmidlands-boun...@openstreetmap.org] On Behalf Of Brian Prangle Sent: 31 March 2009 9:46 AM To: talk-gb-westmidla...@openstreetmap.org; talk-transit@openstreetmap.org ; Thomas Wood Subject: [Talk-gb-westmidlands] Naptan alignment Thomas I've also looked at Google maps and their alignment is off too in exactly the same way ours is in areas I know well and have surveyed, so I guess it's down to the NaPTAN data. There are examples where I know the bus stops are in a row along the street (Corporation Street and Acocks Green Village for example) but NapTAN has one or two skewed from the line by several metres. Currently I favour correcting the NapTAN data to what we know on the ground, but until a consensus emerges I'm laying off the urge to correct it. Regards Brian ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [OSM-talk] Category:TagsSupportedBy
On Mon, 30 Mar 2009 21:34:36 +0200, Tobias Knerr o...@tobias-knerr.de
wrote:
A relation isn't just a set of tags. It requires certain members and
roles (which aren't tags). Thus, a relation isn't, as the category name
would suggest, a tag supported by X (it's a relation supported by X),
whereas the relation's type=xyz tag would indeed be a tag supported by
X. But that's not a very relevant issue.
I have not seen any valir relation without a type -tag yet.
After all, you need to know in what way (and not just in what role)
they are related.
Well, I'm no MediaWiki expert either, so I'm not sure about the best way
of creating that sort of template.
Something like Babel (http://wiki.openstreetmap.org/wiki/Template:Babel)
templates would probably be easy, but I've got no idea what the
performance effects of something like that would be.
I've never seen that
{{#if:{{{1|}}}|XXX}} -construct.
Is that a mediawiki-plugin?
Marcus
Anyway, I'd definitely like a statement from someone with MediaWiki
experience before creating some widely-used template. Of course,
categories are the simpler solution and could theoretically be exchanged
with something else by a bot if we encounter problems.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging best practices
On Mon, 30 Mar 2009 15:53:12 -0400, PAA poule...@gmail.com wrote: What is the preferred way to design tags: First scenario * One key, multiple values * Multiple keys, single values Using the proposed shop=pet as an example: * grooming=yes: The shop offers pet grooming services * kennel=yes: The shop offers kennel (pet keeping or tending) services * training=yes: The shop offers obedience training services Or * service=(grooming;kennel;training) shop:pet:grooming=yes shop:pet:kennel=yes shop:pet:training=yes sounds reasonable. Second scenario *One node, multiple functions *Multiple nodes, single functions The example for this scenario is a subway entrance that is also a bus station entrance. Should the node be tagged both railway=subway_entrance and amenity=bus_station (er...think it's amenity), or should two nodes be created, even though there is one entrance (the same situation could as easily apply to an area, too. If it's in the exact same location and tagging is possible, I suggest using one node tagged as both. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Category:TagsSupportedBy
Hi,
2009/3/31 marcus.wolsc...@googlemail.com:
On Mon, 30 Mar 2009 21:34:36 +0200, Tobias Knerr o...@tobias-knerr.de
wrote:
Something like Babel (http://wiki.openstreetmap.org/wiki/Template:Babel)
templates would probably be easy, but I've got no idea what the
performance effects of something like that would be.
I've never seen that
{{#if:{{{1|}}}|XXX}} -construct.
Is that a mediawiki-plugin?
It's pure MediaWiki (a parser function).
Not very cost-intensive, I don't expect any problems even if used excessively.
Bye, Tim.
--
http://wikipedistik.de
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Category:TagsSupportedBy
marcus.wolsc...@googlemail.com wrote:
Something like Babel (http://wiki.openstreetmap.org/wiki/Template:Babel)
templates would probably be easy, but I've got no idea what the
performance effects of something like that would be.
I've never seen that
{{#if:{{{1|}}}|XXX}} -construct.
Is that a mediawiki-plugin?
http://www.mediawiki.org/wiki/Extension:ParserFunctions
http://www.mediawiki.org/wiki/Help:Extension:ParserFunctions
Didn't even know it was an extension until now, as many major wikis
(especially Wikimedia's) seem to have it installed.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Category:TagsSupportedBy
On Tue, 31 Mar 2009 08:45:12 +0200, Tobias Knerr o...@tobias-knerr.de
wrote:
marcus.wolsc...@googlemail.com wrote:
Something like Babel
(http://wiki.openstreetmap.org/wiki/Template:Babel)
templates would probably be easy, but I've got no idea what the
performance effects of something like that would be.
I've never seen that
{{#if:{{{1|}}}|XXX}} -construct.
Is that a mediawiki-plugin?
http://www.mediawiki.org/wiki/Extension:ParserFunctions
http://www.mediawiki.org/wiki/Help:Extension:ParserFunctions
Didn't even know it was an extension until now, as many major wikis
(especially Wikimedia's) seem to have it installed.
I've written quite complex mediawiki-extensions myself.
Thus I was puzzled that this would be in the core. I
would have been bound to see it a some point. ;)
(It does not seem to be installed in the Sourceforge-hosted mediawiki.
I'm getting quite frustrated with the limitations they have compared
to installing y mediawiki/phpBB/... yourself in Sourceforge.)
Marcus
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging best practices
PAA schrieb: Using the proposed shop=pet as an example: * grooming=yes: The shop offers pet grooming services * kennel=yes: The shop offers kennel (pet keeping or tending) services * training=yes: The shop offers obedience training services Or * service=(grooming;kennel;training) I suggest using the first variant. It's easier for existing tools to evaluate, because they usually can't handle semicolon-separated values (these are just a relatively common convention, after all). Also, duplicates are prevented automatically. Additionally, separate keys are better if you want to use implied values. That doesn't make much sense for your example, but it's an advantage of that variant in general. If pet shops e.g. usually offered a certain set of services and that was a widely accepted fact, it would be possible to make that information implicit. With the second variant, it then wouldn't be possible to remove one implied service for a certain shop (due to the lack of a =no option). No matter which variant you choose, you might want to add a prefix/namespace to those keys, which was done e.g. for recycling keys: http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drecycling It helps to avoid key name conflicts. (I'd expect training or service to be used in other contexts, too, which would make validation and documentation tricky.) It also is convenient when keys are sorted alphabetically. I'd probably use pet:* rather than of shop:pet:* because the keys would be useful for other providers of pet related services, too, not just shops. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging best practices
PAA wrote: What is the preferred way to design tags: http://wiki.openstreetmap.org/wiki/Any_tags_you_like#Syntactic_conventions_for_new_tags or in short, http://tinyurl.com/crphdw#Syntactic_conventions_for_new_tags Although there's no preferred here, those are merely some observed conventions. First scenario * One key, multiple values * Multiple keys, single values Using the proposed shop=pet as an example: * grooming=yes: The shop offers pet grooming services * kennel=yes: The shop offers kennel (pet keeping or tending) services * training=yes: The shop offers obedience training services Semicolons in tag values are much less widespread than some of the wiki pages would have you believe. I prefer the style above to the other. It's easier to program too, since no value-interpretation is involved. Because there's a lot of possibilities here, and words like training shouldn't be limited by definition to pet training and nor should they be purely contextual in interpretation, I would suggest using a namespace prefix; something along the lines of shop=pet pet:grooming=yes pet:kennel=yes pet:training=yes This is patterned along the lines of the way payment types are done for amenity=telephone in presets.xml and the way recycling materials are done for amenity=recycling : see http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drecycling . Lots of established practice to draw from here. You also have the opportunity to expand on what sorts of kennels are available, the styles of training available, whatever (...don't know the problem space that well here...). -- Andrew Chadwick ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
This talk of turn restriction relations reminds me of a junction where I think I need to add loads of relations, but to date haven't as many of them will include a roundabout as the from or to part. http://is.gd/pOrJ (shortened permalink) As you can see there is a roundabout, but there is also a dual carriageway through the middle with the flow controlled by traffic lights. If you are in the lanes which go through as the dual carriageway you can't turn onto the roundabout, and if you are in the lanes that lead onto the roundabout you can't turn onto the dual carriageway lanes. I think for the relations to work I might have to split the roundabout from a closed way into a number of sections, but I've always drawn roundabouts as closed ways before. Will splitting it cause issues with anything else? Although I might not have to split as the via (node) will indicate where the restriction actually applies, even when the dual carriageway lane crosses the roundabout at two nodes. Or perhaps I could just split the dual carriageway lanes somewhere in the middle of the roundabout to make things easier for me to work out what restrictions I need to add. Comments welcome. I'm undecided between only_straight_on and no_left_turn on the dual carriageway segments where they cross the roundabout (and on the roundabout where it crosses the dual carriageway). I think perhaps the first. Which I think means I need to add 8 relations to the junction. Ed ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
I have something which resembles that junction of yours near my home, here's how I mapped it: a roundabout way split in 4 plus 4 turn only_straight_on restrictions where necessary. See it here: http://osm.virtuelle-loipe.de/restrictions/?zoom=18lat=48.97982lon=2.2923layers=B00TT Yann Le 31 mars 09 à 11:05, Ed Loach a écrit : This talk of turn restriction relations reminds me of a junction where I think I need to add loads of relations, but to date haven't as many of them will include a roundabout as the from or to part. http://is.gd/pOrJ (shortened permalink) As you can see there is a roundabout, but there is also a dual carriageway through the middle with the flow controlled by traffic lights. If you are in the lanes which go through as the dual carriageway you can't turn onto the roundabout, and if you are in the lanes that lead onto the roundabout you can't turn onto the dual carriageway lanes. I think for the relations to work I might have to split the roundabout from a closed way into a number of sections, but I've always drawn roundabouts as closed ways before. Will splitting it cause issues with anything else? Although I might not have to split as the via (node) will indicate where the restriction actually applies, even when the dual carriageway lane crosses the roundabout at two nodes. Or perhaps I could just split the dual carriageway lanes somewhere in the middle of the roundabout to make things easier for me to work out what restrictions I need to add. Comments welcome. I'm undecided between only_straight_on and no_left_turn on the dual carriageway segments where they cross the roundabout (and on the roundabout where it crosses the dual carriageway). I think perhaps the first. Which I think means I need to add 8 relations to the junction. Ed ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
-Original Message- From: talk-boun...@openstreetmap.org [mailto:talk- boun...@openstreetmap.org] On Behalf Of Shaun McDonald Sent: 31 March 2009 10:39 To: Ed Loach Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] turn restriction relations: via On 31 Mar 2009, at 10:05, Ed Loach wrote: This talk of turn restriction relations reminds me of a junction where I think I need to add loads of relations, but to date haven't as many of them will include a roundabout as the from or to part. http://is.gd/pOrJ (shortened permalink) As you can see there is a roundabout, but there is also a dual carriageway through the middle with the flow controlled by traffic lights. If you are in the lanes which go through as the dual carriageway you can't turn onto the roundabout, and if you are in the lanes that lead onto the roundabout you can't turn onto the dual carriageway lanes. I think for the relations to work I might have to split the roundabout from a closed way into a number of sections, but I've always drawn roundabouts as closed ways before. Will splitting it cause issues with anything else? Although I might not have to split as the via (node) will indicate where the restriction actually applies, even when the dual carriageway lane crosses the roundabout at two nodes. Or perhaps I could just split the dual carriageway lanes somewhere in the middle of the roundabout to make things easier for me to work out what restrictions I need to add. I have seen some people splitting roundabouts so that the bridge can be shown properly. Also, there's a roundabout that's split into three separate ways in Canterbury, because it's actually a different road name for each of those ways. I've also seen several examples of roundabouts being split to accommodate bridges, particularly at motorway junctions. Comments welcome. I'm undecided between only_straight_on and no_left_turn on the dual carriageway segments where they cross the roundabout (and on the roundabout where it crosses the dual carriageway). I think perhaps the first. Which I think means I need to add 8 relations to the junction. I think the only straight on restriction might be a better option. Shaun Ed ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Allowed ? GSoC'09
Thank you everybody,That's a great help.I am comfortable to choose any language for the same,may be it will depend on what language my mentor is comfortable with (if I get accepted).I am keen to develop direction tool for visually impaired people (and general users for sure).Have submitted the proposal now. Thanks again :) Rajan On Mon, Mar 30, 2009 at 6:20 PM, Nick Black nickbla...@gmail.com wrote: On Sun, Mar 29, 2009 at 11:43 PM, Frederik Ramm frede...@remote.orgwrote: Hi, Nick Black wrote: Just to be clear the Personal Use parts of the CloudMade TCs refer to the site contents and use of the website - cloudmade.com, rather than any of the APIs and web service. You, and everyone else are welcome to use CloudMade's APIs, web services and the documentation provided on the site in personal, public or business uses. Sorry for misrepresenting that then! I read about the personal use in the Ts and Cs and thought well it cannot probably mean that they don't want business users to look at their web page so it must mean the tiles/services/APIs. No problem :-) It would be great if you could link to http://developers.cloudmade.com/projects/web-maps-lite/terms http://www.cloudmade.com/products/libraries_apis/terms_of_use from http://cloudmade.com/terms_conditions because the latter is the one that you find when you google for cloudmade terms and conditions! Good feedback - we could definitely make the TCs more clear. Cheers, Bye Frederik -- -- Nick Black twitter.com/nick_b ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
Gregory Williams wrote: -Original Message- From: talk-boun...@openstreetmap.org [mailto:talk- boun...@openstreetmap.org] On Behalf Of Shaun McDonald I have seen some people splitting roundabouts so that the bridge can be shown properly. Also, there's a roundabout that's split into three separate ways in Canterbury, because it's actually a different road name for each of those ways. I've also seen several examples of roundabouts being split to accommodate bridges, particularly at motorway junctions. Or routes. There is no reason why a roundabout should consist of only one way. If need be, a relation can be created to include all ways in a roundabout. Roundabouts in the Netherlands (from the AND import) are generally split in a different segment on each point where a road joins it. Random example: http://www.openstreetmap.org/?lat=52.51517lon=6.102627zoom=18layers=B000FTF. This is a typical example. Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
As you can see there is a roundabout, but there is also a dual carriageway through the middle with the flow controlled by traffic lights. If you are in the lanes which go through as the dual carriageway you can't turn onto the roundabout, and if you are in the lanes that lead onto the roundabout you can't turn onto the dual carriageway lanes. I think for the relations to work I might have to split the roundabout from a closed way into a number of sections, but I've always drawn roundabouts as closed ways before. Will splitting it cause issues with anything else? Although I might not have to split as the via (node) will indicate where the restriction actually applies, even when the dual carriageway lane crosses the roundabout at two nodes. Or perhaps I could just split the dual carriageway lanes somewhere in the middle of the roundabout to make things easier for me to work out what restrictions I need to add. I haven't thought this through, but I wonder if you could add relations to describe road groups, putting all the dual carriageway ways in one relation, and all the roundabout and link ways in another, and then adding a turns_prohibited restriction between those two relations. This seems pleasing since there is logically one extra rule to explain to humans - no turning between the roundabout and the dual carriageways that cross it. Of course this nested relation/restriction complicates routing software but perhaps not too badly. pgpujQIjlKPzY.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
On Tue, 31 Mar 2009 08:55:54 -0400, Greg Troxel g...@ir.bbn.com wrote: As you can see there is a roundabout, but there is also a dual carriageway through the middle with the flow controlled by traffic lights. If you are in the lanes which go through as the dual carriageway you can't turn onto the roundabout, and if you are in the lanes that lead onto the roundabout you can't turn onto the dual carriageway lanes. I think for the relations to work I might have to split the roundabout from a closed way into a number of sections, but I've always drawn roundabouts as closed ways before. Will splitting it cause issues with anything else? Although I might not have to split as the via (node) will indicate where the restriction actually applies, even when the dual carriageway lane crosses the roundabout at two nodes. Or perhaps I could just split the dual carriageway lanes somewhere in the middle of the roundabout to make things easier for me to work out what restrictions I need to add. I haven't thought this through, but I wonder if you could add relations to describe road groups, putting all the dual carriageway ways in one relation, and all the roundabout and link ways in another, and then adding a turns_prohibited restriction between those two relations. This seems pleasing since there is logically one extra rule to explain to humans - no turning between the roundabout and the dual carriageways that cross it. Of course this nested relation/restriction complicates routing software but perhaps not too badly. There is no need for any additional relations to describe these turn-restrictions. It's just a bunch of only_ahead. However a relation to group the left and right lane of a dual-carriageway is a very welcome thing for many algorithms. What about: type=road to collect the ways of a long street and if it's a dual-carriageway some may have a role of left or right while for single carriageways and sections where the ways are joined temporarily have some other role. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
Date: Tue, 31 Mar 2009 10:05:39 +0100 From: Ed Loach e...@loach.me.uk Subject: Re: [OSM-talk] turn restriction relations: via To: talk@openstreetmap.org Message-ID: 004201c9b1df$e093b650$a1bb22...@me.uk Content-Type: text/plain; charset=Windows-1252 This talk of turn restriction relations reminds me of a junction where I think I need to add loads of relations, but to date haven't as many of them will include a roundabout as the from or to part. http://is.gd/pOrJ (shortened permalink) Could you let us know how you fare? I was just looking at a similar junction in my home town the other day: http://www.openstreetmap.org/?lat=57.70716lon=11.99237zoom=17layers=0B00FFF I'll have to add traffic lights and turn restrictions too. /Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
Oh, and here is a link to a photo of the junction, in case anybody is interested: http://is.gd/pQXb /Martin 2009/3/31 Martin Norbäck mar...@norpan.org: Date: Tue, 31 Mar 2009 10:05:39 +0100 From: Ed Loach e...@loach.me.uk Subject: Re: [OSM-talk] turn restriction relations: via To: talk@openstreetmap.org Message-ID: 004201c9b1df$e093b650$a1bb22...@me.uk Content-Type: text/plain; charset=Windows-1252 This talk of turn restriction relations reminds me of a junction where I think I need to add loads of relations, but to date haven't as many of them will include a roundabout as the from or to part. http://is.gd/pOrJ (shortened permalink) Could you let us know how you fare? I was just looking at a similar junction in my home town the other day: http://www.openstreetmap.org/?lat=57.70716lon=11.99237zoom=17layers=0B00FFF I'll have to add traffic lights and turn restrictions too. /Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] UKUUG : Suggestions
Hi, I've been asked to help coordinate an OpenStreetMap track at the UKUUG Summer conference (http://www.ukuug.org/events/summer2009/). UKUUG is (in my opinion) a hard core techie conference of sys-admins and computer scientists. The conference is being held in Birmingham, and I would have done a mapping party had we not finished mapping Birmimgham 3 months ago. So, I need ideas. We could have a hacking sprint of somekind. But what projects could do with some hacking-love? Bearing in mind you'll have a variety of people and skill sets. We could do tracing as we'll have the wireless access to do so. Can anyone think of anything else? Ciarán ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] request for assistance to import Philippine data from PAFID
hi, PAFID gave OSM Philippines permission to import it's geodata mainly of topographic features based on digitized 1:50K topomaps of the country. The coverage are the mountainous and rural areas of the country where no satellite image or GPS maybe available. Approximately 179 toposheets are available or roughly 18% of the entire 1:50K toposheets of the whole country. I am currently collecting ideas on how we can add the data to OSM here: http://wiki.openstreetmap.org/wiki/WikiProject_Philippines/Data_import/pafid_data To date, this is one the biggest data import we will do for the Philippines and will cover much of the unmapped areas. Please share your insights on how we can implement the import. I am hopeful that the success of this import would pave the way for many geodata silos in the Philippine to donate data to OSM. -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Shakespeare on OSM
OK, this needs a wider audience than just those on IRC: 15:49 zere even Shakespeare is an OSM contributor. look at king henry IV: 15:49 zere Bardolph: We first survey the plot, then draw the model // And when we see the figure of the house // Add the tags building=yes, addr:housenumber=1 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] UKUUG : Suggestions
On 31 Mar 2009, at 15:40, Ciarán Mooney wrote: Hi, I've been asked to help coordinate an OpenStreetMap track at the UKUUG Summer conference (http://www.ukuug.org/events/summer2009/). UKUUG is (in my opinion) a hard core techie conference of sys-admins and computer scientists. I had one of the organisers ask me on Saturday at GLLUG, as they were wanting a mapping track. The conference is being held in Birmingham, and I would have done a mapping party had we not finished mapping Birmimgham 3 months ago. Have all the house numbers been added? How about a check the data mapping party? Or find something that has changed since it was last mapped? So, I need ideas. We could have a hacking sprint of somekind. But what projects could do with some hacking-love? Bearing in mind you'll have a variety of people and skill sets. We could do tracing as we'll have the wireless access to do so. Can anyone think of anything else? How far afield do people come from to go to this event? A hack day to make it easier to edit the data? Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] How to set up a localized mapnik + slippy map web server
Hi, A few clueless people were toying with the Idea of creating a webserver + slippy map in 2 (later 3) languages for Israel (Including the ... ahmm... territories...). We need help understanding what exactly should be done. First and most important: does it cost any money and a rough estimate of the cost if it's not zero. Maybe it's possible to add what we need to an existing osm server? Next, a good way to go about creating 3 maps of the same small country in 3 languages. How much processing power would it take? And anything else you can think of. Thanks, Tal. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to set up a localized mapnik + slippy map web server
On 31 Mar 2009, at 16:07, Tal wrote: Hi, A few clueless people were toying with the Idea of creating a webserver + slippy map in 2 (later 3) languages for Israel (Including the ... ahmm... territories...). We need help understanding what exactly should be done. First and most important: does it cost any money and a rough estimate of the cost if it's not zero. Maybe it's possible to add what we need to an existing osm server? Its all free software... See http://wiki.openstreetmap.org/wiki/Mapnik -- Chris Jones, SUCS Admin http://sucs.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [Announcement] talk-ps Palestine mailing list
There is now a talk-cr - Costa Rica-specific topics and discussion mailing list available. Thank you to Mikel Maron for initiating and hosting this forum. For details on how to subscribe to this and other country, language, and topic-specific OSM mailing lists, see http://wiki.openstreetmap.org/index.php/Mailing_lists For details about OSM activity in Palestine: http://wiki.openstreetmap.org/wiki/WikiProject_Palestine About Costa Rica: http://en.wikipedia.org/wiki/Palestine Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Announcement] talk-ps Palestine mailing list
wow, Costa Rica? Palestine? both? none? I wonder what your map looks like cheers Lucas There is now a talk-cr - Costa Rica-specific topics and discussion mailing list available. Thank you to Mikel Maron for initiating and hosting this forum. For details on how to subscribe to this and other country, language, and topic-specific OSM mailing lists, see http://wiki.openstreetmap.org/index.php/Mailing_lists For details about OSM activity in Palestine: http://wiki.openstreetmap.org/wiki/WikiProject_Palestine About Costa Rica: http://en.wikipedia.org/wiki/Palestine Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] GroundTruth v1.3 - Garmin maps with relief contours
Hello everybody, GroundTruth, a mapmaking software for Gamin GPS units, has a new version. GroundTruth can now generate relief contours from SRTM data using the Isohypse Binary File (IBF) format. The format enables much more compact storage of contours (up to 100 times smaller than using OSM XML files). If you're interested, here are some links you can check out: - http://igorbrejc.net/openstreetmap/groundtruth-v13 - http://wiki.openstreetmap.org/wiki/GroundTruth_For_Dummies#Generating_Maps_With_Relief_Contours - http://wiki.openstreetmap.org/wiki/Isohypse_Binary_File - http://www.flickr.com/photos/28786...@n03/tags/groundtruth/ - contains various screenshots taken from GroundTruth maps I'll be releasing a C# library for manipulating IBF files soon. Enjoy, Igor -- http://igorbrejc.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Connecting tags using array syntax
Hi, Candid Dauth wrote: 1. Different things in one node or area have different opening hours. For example, there are multiple shops with different opening hours on different floors of a building. Or an ATM in the entrance hall of a bank, the ATM being opened at different hours than the bank itself. Or a recycling container where you are allowed to put in paper and glass, but glass only at certain hours to avoid being too loud. At the moment, you have to create two different nodes next to each other, which does not always represent the real situation. These should probably be fleshed out by giving them individual geometries, since they are not by nature in one node, only because their geometry has not been mapped more precisely. Your other examples are discussed to death every other month so I'm quite surprised you did not find anything on them. People often suggest things like maxspeed:hgv to make a limit apply only to one class of vehicles. Since you might be capable of understanding German, the talk-de list has discussions about these in regular intervals. You might want to check out http://lists.openstreetmap.org/pipermail/talk-de/2008-August/020217.html and related discussions in the same month, or http://lists.openstreetmap.org/pipermail/talk-de/2009-February/037417.html Also, about the pavement on both sides with different surfaces issue, check out http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Workshops/Linienb%C3%BCndel which doesn't come to a conclusion but maybe at least tells the story of how many people have thought about this and how unsatisfactory the results still are ;-) 1. Use “tag arrays”. Tags with the same index are connected to each other, for example an ATM with different opening hours than the bank: * amenity[0]=bank * opening_hours[0]=Mo-Fr 09:00-16:00 * amenity[1]=atm * opening_hours[1]=Mo-Su 06:00-22:00 * name=Deutsche Bank Generally, we try to use tags that can be understood by a human with relative ease. Everybody uses editors to make changes but still, we like our tags to be human readable. Your concept really stretches the envelope of human readability. Of course it is trivial for a computer program to evaluate something like this: * maxspeed[0]=120 * hour_on[0]=6 * hour_off[0]=20 * maxspeed[1]=100 * hour_on[1]=22 * hour_off[1]=6 * maxspeed[2]=60 * hour_on[2]=22 * hour_off[2]=6 * for[2]=hgv and display it in some suitable fashion, but before too long you would really *need* the program to make sense of these things at all. It is possible that we'll one day have to drop the idea of human-readable tagging but I think we're not quite there yet. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM scores at Linux New Media Awards
Blumpsy schrieb: OSM won in two out of six categories: - Outstanding contribution to Open Source / Linux / Free Software, and - Most innovative Open Source Project. Quite why OSM receives a software award escapes me, but I don't want to spoil your excitement. Because we do not only provide data (which is our outstanding contribution award) for OSS projects which otherwise will have no one to go to for geodata, but also contribute to the Geo-OSS ecosystem as well. (Have a look at our svn if you have doubts). Anyway, it was great fun ;) -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to set up a localized mapnik + slippy map web server
On Tuesday 31 March 2009 21:15:28 Chris Jones wrote: A few clueless people were toying with the Idea of creating a webserver + slippy map in 2 (later 3) languages for Israel (Including the ... ahmm... territories...). We need help understanding what exactly should be done. First and most important: does it cost any money and a rough estimate of the cost if it's not zero. Maybe it's possible to add what we need to an existing osm server? Its all free software... See http://wiki.openstreetmap.org/wiki/Mapnik just remember - you need the lastest distros to do this, FC10 or Debian Lenny etc -- regards Kenneth Gonsalves Associate NRC-FOSS http://nrcfosshelpline.in/web/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatch niet meer
Ik had eerst iets heel anders willen posten, maar dat doe ik maar niet. Heb je een lijst van gebruikers - toptien ofzo - en sta ik daar op? In dat geval denk ik dat ik de pijp aan Maarten geef. Waar is die dev-lijst? Groeten Taede. -Original Message- From: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] On Behalf Of Stefan de Konink Sent: dinsdag 31 maart 2009 6:37 To: OpenStreetMap NL discussion list Subject: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatch niet meer Eigenlijk zoals de titel zegt. Ik ben nu al dagen bezig (dwijlen met de kraan open) om de OSM data set met referenties te laten kloppen, slechts een uniek voorkomen van een tag k/v-paar te bewerkstelligen eigenlijk alles om voor mensen die ooit nog eens naar 0.6 willen verkassen de weg zo rustig mogelijk te laten verlopen. Echter; alle fouten die ik momenteel vindt, zijn gecreëerd door of met Potlatch. Daar is geen enkele uitzondering op. Ik zou daarom iedereen die in ons mooie landje edit willen vragen om Potlatch niet meer te gebruiken, zeker niet om bestaande wegen en/of relaties aan te passen. Er zijn andere tools, ze werken nog prettiger ook. http://wiki.openstreetmap.org/wiki/Merkaartor http://wiki.openstreetmap.org/wiki/JOSM Meer informatie kun je vinden op de dev lijst, waar ik in de afgelopen dagen meer dan 60.000 fouten heb gefixed. En vandaag weer 5000 nieuwe fouten tegen kwam, plus een compleet kapotte way. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatch niet meer
Hallo, Wow, dat is nog eens een bom laten vallen, zeg. In zo'n geval zou ik misschien eens beginnen met: Het lijkt erop dat Potlatch nogal veel problemen veroorzaakt, kunnen we daar niet een keer een oplossing voor vinden? Ik heb JOSM wel op mn pc maar ik gebruik het alleen om mn gebouwen mooi rechthoekig te krijgen! Het is imho te IT-minded. Maw minder intuitief. Potlatch daarentegen is een echte no-fuss editor. Veel fijner in het gebruik. En ik heb het echt al een paar keer geprobeerd met JOSM. Kan je de percentages achterhalen van hoeveel users de 3 hoofd-editors gebruiken? - Oorspronkelijk bericht - Van: Taede @ orange taede.terps...@orange.nl Verzonden: dinsdag 31 maart 2009 8:09 Aan: 'OpenStreetMap NL discussion list' talk-nl@openstreetmap.org Onderwerp: Re: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatchniet meer Ik had eerst iets heel anders willen posten, maar dat doe ik maar niet. Heb je een lijst van gebruikers - toptien ofzo - en sta ik daar op? In dat geval denk ik dat ik de pijp aan Maarten geef. Waar is die dev-lijst? Groeten Taede. -Original Message- From: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] On Behalf Of Stefan de Konink Sent: dinsdag 31 maart 2009 6:37 To: OpenStreetMap NL discussion list Subject: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatch niet meer Eigenlijk zoals de titel zegt. Ik ben nu al dagen bezig (dwijlen met de kraan open) om de OSM data set met referenties te laten kloppen, slechts een uniek voorkomen van een tag k/v-paar te bewerkstelligen eigenlijk alles om voor mensen die ooit nog eens naar 0.6 willen verkassen de weg zo rustig mogelijk te laten verlopen. Echter; alle fouten die ik momenteel vindt, zijn gecreëerd door of met Potlatch. Daar is geen enkele uitzondering op. Ik zou daarom iedereen die in ons mooie landje edit willen vragen om Potlatch niet meer te gebruiken, zeker niet om bestaande wegen en/of relaties aan te passen. Er zijn andere tools, ze werken nog prettiger ook. http://wiki.openstreetmap.org/wiki/Merkaartor http://wiki.openstreetmap.org/wiki/JOSM Meer informatie kun je vinden op de dev lijst, waar ik in de afgelopen dagen meer dan 60.000 fouten heb gefixed. En vandaag weer 5000 nieuwe fouten tegen kwam, plus een compleet kapotte way. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatch niet meer
Op dinsdag 31-03-2009 om 09:17 uur [tijdzone +0200], schreef Hans van Wijk: Ik heb JOSM wel op mn pc maar ik gebruik het alleen om mn gebouwen mooi rechthoekig te krijgen! Het is imho te IT-minded. Maw minder intuitief. Potlatch daarentegen is een echte no-fuss editor. Veel fijner in het gebruik. En ik heb het echt al een paar keer geprobeerd met JOSM. Ik begrijp de frustratie als je 6 problemen moet oplossen door deze tool en dat je dan deze oplossing wil toepassen. Ik ben ooit een keer begonnen met JOSM maar ging weer snel naar Potlatch. En dan ben ik zelf nog software ontwikkelaar van beroep. Ik heb daarna nooit meer iets anders gebruikt dan Potlatch (al heb ik in de afgelopen winter weinig aan OSM gedaan, het mooie weer komt er weer aan). Het lijkt mij verstandig als de OSM-community de problemen van Potlatch aanpakt (het is hét programma wat gelinkt wordt direct in de kaart onder edit) in plaats van te stellen dat we het niet meer gebruikt moet worden. En zoals Hans hierboven schrijft, een intuïtief programma is gewoon handiger in gebruik. Met vriendelijke groet, Martijn Coenen ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatchniet meer
Het is waar. Potlatch is in de huidige versie niet toegerust om in high density gebieden te editen. Ook ik wil een ieder aanraden (in het belang van de map) wat tijd te steken in JOSM. Het is echt makkelijker dan je in eerste instantie denkt. Er zijn de volgende problemen met editen: -er is een zoomlevel te kort -potlatch staat standaard met vette lijnen aan, waardoor je niet goed kan zien wat je doet regelmatig tref ik kruispunten aan waar je kan zien aan de route die wegstukjes volgen dat de gebruiker 4x of 5x heeft geklikt voordat de connectie is gemaakt. - potlatch is te traag op minder snelle computers - er zijn integriteitsproblemen met de real time update van data. Verder is Potlatch is de editor waar OSM beginners tegen aan lopen, en beginners maken van nature al meer fauten. Ik heb op OSM talk een discussie gestart over de toekomst van Potlatch, maar werd zowat afgebrand omdat ik het waagde om Potlatch ter discussie te stellen. Er zijn daar een paar Engelsen die echt de OSM wijsheid in pacht denken te hebben en absoluut niet openstaan voor kritiek. Je mag in die groep alleen kritiek hebben als je mee-programmeert. Als gebruiker moet je je mond houden. Met name Richard Fairhurst als auteur van Potlatch gedraagt zich als zelfgekozen koning. Toch was OSM niet bedoeld als een programmeurs club, maar een cartografie club, dacht ik. De laatste jaren is het accent teveel bij de software jongens komen te liggen, ik begrijp dat best, want OSM staat of valt met goede software, maar dat is niet de enige belangrijke kant van OSM. Ik wil best een middag organiseren voor Potlatch gebruikers die willen overstappen naar JOSM. Er is vast ook wel iemand die Merkaartor wil uitleggen. Geef me even een seintje als je mee wilt doen, zowel aan de vraag als aanbodzijde. Lambertus, kan jij die oproep doorgeven aan de forum-lezers ??? Gert Gremmen - Openstreetmap.nl (alias: cetest) Before printing, think about the environment. -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Stefan de Konink Verzonden: Tuesday, March 31, 2009 6:37 AM Aan: OpenStreetMap NL discussion list Onderwerp: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatchniet meer Eigenlijk zoals de titel zegt. Ik ben nu al dagen bezig (dwijlen met de kraan open) om de OSM data set met referenties te laten kloppen, slechts een uniek voorkomen van een tag k/v-paar te bewerkstelligen eigenlijk alles om voor mensen die ooit nog eens naar 0.6 willen verkassen de weg zo rustig mogelijk te laten verlopen. Echter; alle fouten die ik momenteel vindt, zijn gecreëerd door of met Potlatch. Daar is geen enkele uitzondering op. Ik zou daarom iedereen die in ons mooie landje edit willen vragen om Potlatch niet meer te gebruiken, zeker niet om bestaande wegen en/of relaties aan te passen. Er zijn andere tools, ze werken nog prettiger ook. http://wiki.openstreetmap.org/wiki/Merkaartor http://wiki.openstreetmap.org/wiki/JOSM Meer informatie kun je vinden op de dev lijst, waar ik in de afgelopen dagen meer dan 60.000 fouten heb gefixed. En vandaag weer 5000 nieuwe fouten tegen kwam, plus een compleet kapotte way. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatchniet meer
Ik moet zeggen dat ik Potlatch alleen gebruik voor een snelle aanpassing, want zodra je meer wilt dan dat beginnen de problemen. Ik vindt JOSM echt een stuk beter wat dat betreft. Als je bijvoorbeeld met CTRL een paar wegdelen selecteert in Potlatch omdat je ze allemaal oneway=yes wilt geven voegt dat k programma alle wegen samen en gooit alle tags op een hoop. Ik begrijp dat het niet leuk is om je enthousiasme getemperd te zien worden door een ingewikkeld programma, maar ik hoop dat iedereen JOSM of Merkaartor een kans geeft. Is niet zo ingewikkeld als het lijkt. Groeten, Geert. - Original Message From: OpenStreetMap NL discussion list talk-nl@openstreetmap.org To: OpenStreetMap NL discussion list talk-nl@openstreetmap.org Subject: Re: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatchniet meer Date: 31/03/09 10:40 Het is waar. Potlatch is in de huidige versie niet toegerust om in high density gebieden te editen. Ook ik wil een ieder aanraden (in het belang van de map) wat tijd te steken in JOSM. Het is echt makkelijker dan je in eerste instantie denkt. Er zijn de volgende problemen met editen: -er is een zoomlevel te kort -potlatch staat standaard met vette lijnen aan, waardoor je niet goed kan zien wat je doet regelmatig tref ik kruispunten aan waar je kan zien aan de route die wegstukjes volgen dat de gebruiker 4x of 5x heeft geklikt voordat de connectie is gemaakt. - potlatch is te traag op minder snelle computers - er zijn integriteitsproblemen met de real time update van data. Verder is Potlatch is de editor waar OSM beginners tegen aan lopen, en beginners maken van nature al meer quot;fautenquot;. Ik heb op OSM talk een discussie gestart over de toekomst van Potlatch, maar werd zowat afgebrand omdat ik het waagde om Potlatch ter discussie te stellen. Er zijn daar een paar Engelsen die echt de OSM wijsheid in pacht denken te hebben en absoluut niet openstaan voor kritiek. Je mag in die groep alleen kritiek hebben als je mee-programmeert. Als gebruiker moet je je mond houden. Met name Richard Fairhurst als auteur van Potlatch gedraagt zich als zelfgekozen koning. Toch was OSM niet bedoeld als een programmeurs club, maar een cartografie club, dacht ik. De laatste jaren is het accent teveel bij de software jongens komen te liggen, ik begrijp dat best, want OSM staat of valt met goede software, maar dat is niet de enige belangrijke kant van OSM. Ik wil best een middag organiseren voor Potlatch gebruikers die willen overstappen naar JOSM. Er is vast ook wel iemand die Merkaartor wil uitleggen. Geef me even een seintje als je mee wilt doen, zowel aan de vraag als aanbodzijde. Lambertus, kan jij die oproep doorgeven aan de forum-lezers ??? Gert Gremmen - Openstreetmap.nl (alias: cetest) ï Before printing, think about the environment. -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Stefan de Konink Verzonden: Tuesday, March 31, 2009 6:37 AM Aan: OpenStreetMap NL discussion list Onderwerp: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatchniet meer Eigenlijk zoals de titel zegt. Ik ben nu al dagen bezig (dwijlen met de kraan open) om de OSM data set met referenties te laten kloppen, slechts een uniek voorkomen van een tag k/v-paar te bewerkstelligen eigenlijk alles om voor mensen die ooit nog eens naar 0.6 willen verkassen de weg zo rustig mogelijk te laten verlopen. Echter; alle fouten die ik momenteel vindt, zijn gecreëerd door of met Potlatch. Daar is geen enkele uitzondering op. Ik zou daarom iedereen die in ons mooie landje edit willen vragen om Potlatch niet meer te gebruiken, zeker niet om bestaande wegen en/of relaties aan te passen. Er zijn andere tools, ze werken nog prettiger ook. http://wiki.openstreetmap.org/wiki/Merkaartor http://wiki.openstreetmap.org/wiki/JOSM Meer informatie kun je vinden op de dev lijst, waar ik in de afgelopen dagen meer dan 60.000 fouten heb gefixed. En vandaag weer 5000 nieuwe fouten tegen kwam, plus een compleet kapotte way. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Message sent using UebiMiau 2.7.10 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatchniet meer
Er zijn de volgende problemen met editen: -er is een zoomlevel te kort -potlatch staat standaard met vette lijnen aan, waardoor je niet goed kan zien wat je doet regelmatig tref ik kruispunten aan waar je kan zien aan de route die wegstukjes volgen dat de gebruiker 4x of 5x heeft geklikt voordat de connectie is gemaakt. - potlatch is te traag op minder snelle computers - er zijn integriteitsproblemen met de real time update van data. Er is nog funding? Kun je een developer inhuren die deze punten oplost (behalve 'te traag op minder snelle computers' wellicht)? Desnoods door een commercieel bedrijf in in te huren als het niet lukt om te werven in de community? Verder is Potlatch is de editor waar OSM beginners tegen aan lopen, en beginners maken van nature al meer fauten. En dat is meteen ook de kracht van Potlatch. Zeker als 'cartografieclub' wil je een zo laag als mogelijk deelnamedrempel en zo veel als mogelijk verbeteringen. Door Potlatch niet meer te laten gebruiken gooi je het kind met het badwater weg, so to speak. Groet, Zoran ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatchniet meer
JOSM is ook niet stil blijven staan, dus als je al een jaar niet meer naar JOSM gekeken hebt moet je dat echt weer eens een keer doen. Zeker als je met toetsenbord en muis tegelijk werkt (s voor select, a voor add/toevoegen) kun je supersnel werken in JOSM. Er is nu ook een direct van het web startende versie, voor als je al java geinstalleerd heb staan: http://josm.openstreetmap.de/download/josm.jnlp Groet, Floris Ik moet zeggen dat ik Potlatch alleen gebruik voor een snelle aanpassing, want zodra je meer wilt dan dat beginnen de problemen. Ik vindt JOSM echt een stuk beter wat dat betreft. Als je bijvoorbeeld met CTRL een paar wegdelen selecteert in Potlatch omdat je ze allemaal oneway=yes wilt geven voegt dat k programma alle wegen samen en gooit alle tags op een hoop. Ik begrijp dat het niet leuk is om je enthousiasme getemperd te zien worden door een ingewikkeld programma, maar ik hoop dat iedereen JOSM of Merkaartor een kans geeft. Is niet zo ingewikkeld als het lijkt. Groeten, Geert. - Original Message From: OpenStreetMap NL discussion list talk-nl@openstreetmap.org To: OpenStreetMap NL discussion list talk-nl@openstreetmap.org Subject: Re: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatchniet meer Date: 31/03/09 10:40 Het is waar. Potlatch is in de huidige versie niet toegerust om in high density gebieden te editen. Ook ik wil een ieder aanraden (in het belang van de map) wat tijd te steken in JOSM. Het is echt makkelijker dan je in eerste instantie denkt. Er zijn de volgende problemen met editen: -er is een zoomlevel te kort -potlatch staat standaard met vette lijnen aan, waardoor je niet goed kan zien wat je doet regelmatig tref ik kruispunten aan waar je kan zien aan de route die wegstukjes volgen dat de gebruiker 4x of 5x heeft geklikt voordat de connectie is gemaakt. - potlatch is te traag op minder snelle computers - er zijn integriteitsproblemen met de real time update van data. Verder is Potlatch is de editor waar OSM beginners tegen aan lopen, en beginners maken van nature al meer quot;fautenquot;. Ik heb op OSM talk een discussie gestart over de toekomst van Potlatch, maar werd zowat afgebrand omdat ik het waagde om Potlatch ter discussie te stellen. Er zijn daar een paar Engelsen die echt de OSM wijsheid in pacht denken te hebben en absoluut niet openstaan voor kritiek. Je mag in die groep alleen kritiek hebben als je mee-programmeert. Als gebruiker moet je je mond houden. Met name Richard Fairhurst als auteur van Potlatch gedraagt zich als zelfgekozen koning. Toch was OSM niet bedoeld als een programmeurs club, maar een cartografie club, dacht ik. De laatste jaren is het accent teveel bij de software jongens komen te liggen, ik begrijp dat best, want OSM staat of valt met goede software, maar dat is niet de enige belangrijke kant van OSM. Ik wil best een middag organiseren voor Potlatch gebruikers die willen overstappen naar JOSM. Er is vast ook wel iemand die Merkaartor wil uitleggen. Geef me even een seintje als je mee wilt doen, zowel aan de vraag als aanbodzijde. Lambertus, kan jij die oproep doorgeven aan de forum-lezers ??? Gert Gremmen - Openstreetmap.nl (alias: cetest) ï Before printing, think about the environment. -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Stefan de Konink Verzonden: Tuesday, March 31, 2009 6:37 AM Aan: OpenStreetMap NL discussion list Onderwerp: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatchniet meer Eigenlijk zoals de titel zegt. Ik ben nu al dagen bezig (dwijlen met de kraan open) om de OSM data set met referenties te laten kloppen, slechts een uniek voorkomen van een tag k/v-paar te bewerkstelligen eigenlijk alles om voor mensen die ooit nog eens naar 0.6 willen verkassen de weg zo rustig mogelijk te laten verlopen. Echter; alle fouten die ik momenteel vindt, zijn gecreëerd door of met Potlatch. Daar is geen enkele uitzondering op. Ik zou daarom iedereen die in ons mooie landje edit willen vragen om Potlatch niet meer te gebruiken, zeker niet om bestaande wegen en/of relaties aan te passen. Er zijn andere tools, ze werken nog prettiger ook. http://wiki.openstreetmap.org/wiki/Merkaartor http://wiki.openstreetmap.org/wiki/JOSM Meer informatie kun je vinden op de dev lijst, waar ik in de afgelopen dagen meer dan 60.000 fouten heb gefixed. En vandaag weer 5000 nieuwe fouten tegen kwam, plus een compleet kapotte way. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatchniet meer
Gert Gremmen wrote: Het is waar. Potlatch is in de huidige versie niet toegerust om in high density gebieden te editen. Ook ik wil een ieder aanraden (in het belang van de map) wat tijd te steken in JOSM. Het is echt makkelijker dan je in eerste instantie denkt. Alle editors hebben een learning curve. Ik zit in Potlatch ook nog vaak te zoeken hoe iets precies ging. Ik heb op OSM talk een discussie gestart over de toekomst van Potlatch, maar werd zowat afgebrand omdat ik het waagde om Potlatch ter discussie te stellen. Er zijn daar een paar Engelsen die echt de OSM wijsheid in pacht denken te hebben en absoluut niet openstaan voor kritiek. Je mag in die groep alleen kritiek hebben als je mee-programmeert. Als gebruiker moet je je mond houden. Met name Richard Fairhurst als auteur van Potlatch gedraagt zich als zelfgekozen koning. Die lijken er in de JOSM community ook te zijn. Een verzoek om een verdwenen functie terug in te bouwen werd beantwoord met tips hoe het te doen zonder die functie en een duidelijke weigering om die functie er terug in te zetten. Dan denk ik ook programmeer je voor jezelf of voor de gebruiker? Ik wil best een middag organiseren voor Potlatch gebruikers die willen overstappen naar JOSM. Er is vast ook wel iemand die Merkaartor wil uitleggen. Geef me even een seintje als je mee wilt doen, zowel aan de vraag als aanbodzijde. Als ik tijd heb wil ik er zeker bij zijn, in het JOSM kamp. Ik gebruik Potlatch ook wel eens voor snelle kleine edits, maar ik wist niet dat die de data zo borkt. @Stefan, is dat altijd of alleen in bepaalde omstandigheden? Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatch niet meer
Wie de internationale mailinglijst volgt weet dat er al tijden problemen zijn met Potlatch (of de API code) maar dat door alle core OSM mensen telkens verwezen wordt naar de komende API 0.6 wisseling, die alle problemen gaat oplossen. Nu komt die API wisseling rap dichterbij en we mogen hopen(!) dat het dan ook de problemen oplost maar daar wachten we dus al zeker een jaar op. Data inconsistentie bij een project dat drijft op die data is redelijk kwalijk in mijn opinie. Trouwens, als pure JOSM gebruiker (ben er gelijk mee begonnen) vind ik Potlatch totaal niet intuitief of nauwkeurig en het heeft ook vage dingen: ik was bezig een hoogspanningslijn te tekenen op basis van Yahoo! verwijnt deze ineens. Ik denk dat ik die lijn per ongeluk gedelete heb dus probeer met U deze weer terug te vinden. Niet dus. Bleek dat ik Potlatch opnieuw moest laden om alles weer terug te krijgen. Hans van Wijk wrote: Hallo, Wow, dat is nog eens een bom laten vallen, zeg. In zo'n geval zou ik misschien eens beginnen met: Het lijkt erop dat Potlatch nogal veel problemen veroorzaakt, kunnen we daar niet een keer een oplossing voor vinden? Ik heb JOSM wel op mn pc maar ik gebruik het alleen om mn gebouwen mooi rechthoekig te krijgen! Het is imho te IT-minded. Maw minder intuitief. Potlatch daarentegen is een echte no-fuss editor. Veel fijner in het gebruik. En ik heb het echt al een paar keer geprobeerd met JOSM. Kan je de percentages achterhalen van hoeveel users de 3 hoofd-editors gebruiken? - Oorspronkelijk bericht - Van: Taede @ orange taede.terps...@orange.nl Verzonden: dinsdag 31 maart 2009 8:09 Aan: 'OpenStreetMap NL discussion list' talk-nl@openstreetmap.org Onderwerp: Re: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatchniet meer Ik had eerst iets heel anders willen posten, maar dat doe ik maar niet. Heb je een lijst van gebruikers - toptien ofzo - en sta ik daar op? In dat geval denk ik dat ik de pijp aan Maarten geef. Waar is die dev-lijst? Groeten Taede. -Original Message- From: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] On Behalf Of Stefan de Konink Sent: dinsdag 31 maart 2009 6:37 To: OpenStreetMap NL discussion list Subject: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatch niet meer Eigenlijk zoals de titel zegt. Ik ben nu al dagen bezig (dwijlen met de kraan open) om de OSM data set met referenties te laten kloppen, slechts een uniek voorkomen van een tag k/v-paar te bewerkstelligen eigenlijk alles om voor mensen die ooit nog eens naar 0.6 willen verkassen de weg zo rustig mogelijk te laten verlopen. Echter; alle fouten die ik momenteel vindt, zijn gecreëerd door of met Potlatch. Daar is geen enkele uitzondering op. Ik zou daarom iedereen die in ons mooie landje edit willen vragen om Potlatch niet meer te gebruiken, zeker niet om bestaande wegen en/of relaties aan te passen. Er zijn andere tools, ze werken nog prettiger ook. http://wiki.openstreetmap.org/wiki/Merkaartor http://wiki.openstreetmap.org/wiki/JOSM Meer informatie kun je vinden op de dev lijst, waar ik in de afgelopen dagen meer dan 60.000 fouten heb gefixed. En vandaag weer 5000 nieuwe fouten tegen kwam, plus een compleet kapotte way. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Doe jezelf en anderen een plezier en gebruik Potlatch niet meer
Ik ben net weer wakker, slapen moet toch ook gebeuren. Taede @ orange wrote: Ik had eerst iets heel anders willen posten, maar dat doe ik maar niet. Heb je een lijst van gebruikers - toptien ofzo - en sta ik daar op? In dat geval denk ik dat ik de pijp aan Maarten geef. Er is geen top tien van 'mensen' die het slopen. Het probleem gebeurt door cascade fouten. Ik heb geaccepteerd dat Potlatch en het stukje wat tussen Potlatch en OSM zit fouten veroorzaakt. Maar als Potlatch daarna ziet dat die fout is op getreden kan daar best wat aan gedaan worden imho. Dus er is geen lijst men mensen die fouten maken, anders stond ik op 1 :) Mijn persoonlijke menining is dat er met de Yahoo API niets beters dan Merkaartor te vinden is :) Waar is die dev-lijst? Dit is de post van gisteravond; daarin staan de volgende 79 ways die bij elkaar ~5000 duizend violations hebben, en de eerste the OSM API laat crashen. http://lists.openstreetmap.org/pipermail/dev/2009-March/014546.html Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-dev] Potlatch RichardF: Sorry
Stefan de Konink wrote: Could anyone with knowledge in ruby *pretty please* take a look at the source code and invent some wheel that Potlatch will never 'reupdate' duplicate k/v-pairs by itself. Today RichardF informed me that 'this' feature exists for Potlatch and therefore the problems that are generated using 'highspeed editing' in relation to the current API that uses unix timestamps with second resolution. In general as was previously pointed out: - it is not Potlatch 'highspeed editing' that a priori does something wrong - theoretically even two different users could cause the same effect using different editors if only their request was processed at exactly the same time Due to the history call not responding for the member issue in question that I was actually pissed of about is still unclear what the reason is that members were in a relation that was actually already deleted before the relation was updated. Potlatch and RichardF are doing a great job to make editing available to the general public. And I am sorry that I currently blame their tool for something that is present already since API 0.5 was released. The promises are there that 'everything works' at 0.6. For the coming weeks I will publish every tag/member that OSM Fixer caught and updates. Please ignore it if you don't want to know, read it if your relation, way or node was edited by me and you want to know why. Again my apologies, Stefan de Konink ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-dev] Potlatch RichardF: Sorry
Apologies OK, Maar het is wel zo dat voornamelijk Potlatch gebruikers Zo intensief real time updaten, terwijl daar eigenlijk geen goede reden voor is. En dit doet niet af aan andere zwakke punten van Potlatch zoals ik die noemde Gert -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Stefan de Konink Verzonden: dinsdag 31 maart 2009 18:56 Aan: OSM-Dev Openstreetmap; OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] [OSM-dev] Potlatch RichardF: Sorry Stefan de Konink wrote: Could anyone with knowledge in ruby *pretty please* take a look at the source code and invent some wheel that Potlatch will never 'reupdate' duplicate k/v-pairs by itself. Today RichardF informed me that 'this' feature exists for Potlatch and therefore the problems that are generated using 'highspeed editing' in relation to the current API that uses unix timestamps with second resolution. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-dev] Potlatch RichardF: Sorry
ce-test, qualified testing bv - Gert Gremmen wrote: Apologies OK, Maar het is wel zo dat voornamelijk Potlatch gebruikers Zo intensief real time updaten, terwijl daar eigenlijk geen goede reden voor is. En batch editing het voorkomt. Kan trouwens voorkomen worden in de huidige API door een queue te introduceren. Maar goed... En dit doet niet af aan andere zwakke punten van Potlatch zoals ik die noemde idd. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-de] Google Maps hat nachgerüstet
Original-Nachricht Datum: Mon, 30 Mar 2009 21:08:54 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Google Maps hat nachgerüstet ganz genau, so ist das, man kann mit Ortskenntnis (und evtl. zusätzlich Luftbildern) eben wesentlich mehr darstellen, als nur das, was eigentlich mit GPS-Genauigkeit geht. Erst Recht, wenn man weitere Bezüge (z.B. Straßenachsen) dazunimmt. Eben, man kann, aber nicht jeder macht es und nicht immer geht das so gut wie im Hofgarten. Wenn ich mich an das damals erinnere, hab ich ein ganzes Weilchen daran hingefeilt, bis alles fuer mein inneres Auge harmonisch war (mit dem josm von 2006!). In normalen Strassenzuegen mit etwas Abschattung habe ich manchmal deutlich mehr Abweichung und dann auch weniger Bezugspunkte fuer die Korrektur. Luftbilder zur Korrektur helfen auch weiter, das aber auch nicht in beliebiger Aufloesung und besonders um relative Abweichungen (z.B. das Verhaeltnis zweier Strassen zueinander) auszugleichen. Ich halte es fuer etwas blauaeugig, wenn man glaubt, der ganze Prozess von Erstellung, Entzerrung bist zum 'unterschieben' im Editor und das Abzeichnen waere ganz allgemein genauer als 5m. Das gilt fuer tracks, Luftbilder und die Kombination davon. Die typische Genauigkeit ist nicht identisch mit der erzielbaren Genauigkeit, denn der menschliche Faktor spielt hier mit rein. Es gibt nicht nur akribische Leute hier, die alle Optionen nutzen, sondern auch Anfaenger, die vieles Verschlimmbessern, durchaus mit guter Absicht. Eine gut ausgemessene Node wird ebensoschnell von einem Anfeanger verschoben wie eine grob geschaetzte. Das wird sich immer auf ein Mittel einpendeln. Ich finde 5-10m Genauigkeit auch absolut ausreichend fuer OSM, ausser man will jeden Pflasterstein einzeln vermessen. Gruesse Hubert -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] openlayers: unterschiedliche Basemap abhaengig von Zoomstufe
Hallo, fuer die Messe AbenteuerAllrad http://wiki.openstreetmap.org/wiki/Abenteuer%26Allrad moechte ich das Messegelaende mit Ausstellern etc. darstellen. OSM reicht hierzu nicht aus und ich moechte ein detailreicheres Image zur Verfuegung stellen. Abhaengig von der Zoomstufe, moechte ich unterschiedliche Basemaps darstellen. Ich haette gerne eine kleinere Zoomstufe (Zoom=19), in der das Image geladen wird, z.B.: zoom=19 - Image zoom=18 - Mapnik zoom=17 - Osmarender zoom=16 - Osmarender ... Leider zaehlt .js nicht zu meinen Lieblingssprachen. Ich bin daher fuer professionelle Hilfe dankbar! Hier meine bescheidenen Anfaenge: http://wiki.openstreetmap.org/wiki/Talk:Abenteuer%26Allrad Viele Gruesse, Dirk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Perl-Zugriff auf OSM-Daten
Am Tuesday 31 March 2009 07:08:34 schrieb Jan Tappenbeck:
Hi !
ich versuche langsam den Einstieg in Perl. Da das OSM-Datenformat
xml-basiert ist suche ich ein einfaches Einsteigerbeispiel für die
Datenfilterung einer Datei. Z.B. alle shop=butcher in der Datei.
Hat einer von Euch ein solches zur Hand und kann es mir zur Verfügung
stellen ?
ungefähr so (hab das aus einer bestehende Datei herausgeschnitten)?
#!/usr/bin/perl -w
use XML::Parser;
sub anfang
{
($wert_des_zeigers,$starttag,%hash) = @_;
if ($starttag eq node) {
$id=$hash{id};
$lat=$hash{lat};
$lon=$hash{lon};
$type=node;
} elsif ($starttag eq tag) {
$k=$hash{k};
$v=$hash{v};
if (($k eq shop) and ($v eq buttcher)) {
print $lat $lon\n;
}
} elsif ($starttag eq way) {
$id=$hash{id};
$type=way;
$lat=;
} elsif ($starttag eq nd) {
$ref=$hash{ref};
if (($lat eq ) and (defined($lath{$ref}))) {
$lat=$lath{$ref};
$lon=$lonh{$ref};
}
push @nodes,$ref;
}
sub ende
{
($wert_des_zeigers,$endtag) = @_;
}
sub inhalt
{
($wert_des_zeigers,$inhalt)=...@_;
#print $inhalt;
}
my $zeiger = new XML::Parser ();
$zeiger-setHandlers (Start = \anfang,End = \ende,Char=\inhalt );
$zeiger-parsefile (Datei.osm);
Gruß
Sven
Gruß Jan :-)
BTW: Bitte lass doch den Inflationären Gebrauch von Simlies, das führt dazu
das ich dich manchmal nicht ernst nehme.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einschränkungen Taggen
Michael Buege schrieb: Wie kann man folgende Wegebeschränkungen Taggen : http://mversen.de/temp/schild.jpg Einzelnd ist das kein Problem, aber wie macht man das in diesem Zusammenhang ? Wenn man davon ausgehen kann, dass dort keine LKWs ueber 3,5t fahren duerfen, Personenkraftwagen und Kraftomnibusse sowie Trecker bis 5t aber wohl, tippe ich mal auf: highway=unbekannt hgv=no (fuer Zeichen 253) access=agricultural (fuer Zeichen 1026-36) maxweight=5 (fuer Zeichen 1052-35) Heisst access=agricultural nicht, dass NUR Agrarfahrzeuge da fahren dürfen? Falls ja, würde ich nur mit hgv=no und maxweight=5t taggen. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einschränkungen Taggen
Heisst access=agricultural nicht, dass NUR Agrarfahrzeuge da fahren dürfen? agricultural als Schlüssel bedeutet Landwirtschaftliche Fahrzeuge agricultural als Wert bedeutet zu landwirtschaftlichen Zwecken erlaubt agricultural=yes = der Bauer darf mit seinem Traktor hier entlang fahren, auch wenn er nicht aufs Feld sondern ins Wirtshaus will access=agricultural = der Bauer darf auch mit dem Auto, aber nur zu lws. Zwecken hier fahren Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Perl-Zugriff auf OSM-Daten
;Moin !
Danke für den Code - das macht das verständnis leichter.
@Roland: Gary68 ist bekannt - auch dafür vielen Dank.
Gruß Jan :-)
Sven Anders schrieb:
Am Tuesday 31 March 2009 07:08:34 schrieb Jan Tappenbeck:
Hi !
ich versuche langsam den Einstieg in Perl. Da das OSM-Datenformat
xml-basiert ist suche ich ein einfaches Einsteigerbeispiel für die
Datenfilterung einer Datei. Z.B. alle shop=butcher in der Datei.
Hat einer von Euch ein solches zur Hand und kann es mir zur Verfügung
stellen ?
ungefähr so (hab das aus einer bestehende Datei herausgeschnitten)?
#!/usr/bin/perl -w
use XML::Parser;
sub anfang
{
($wert_des_zeigers,$starttag,%hash) = @_;
if ($starttag eq node) {
$id=$hash{id};
$lat=$hash{lat};
$lon=$hash{lon};
$type=node;
} elsif ($starttag eq tag) {
$k=$hash{k};
$v=$hash{v};
if (($k eq shop) and ($v eq buttcher)) {
print $lat $lon\n;
}
} elsif ($starttag eq way) {
$id=$hash{id};
$type=way;
$lat=;
} elsif ($starttag eq nd) {
$ref=$hash{ref};
if (($lat eq ) and (defined($lath{$ref}))) {
$lat=$lath{$ref};
$lon=$lonh{$ref};
}
push @nodes,$ref;
}
sub ende
{
($wert_des_zeigers,$endtag) = @_;
}
sub inhalt
{
($wert_des_zeigers,$inhalt)=...@_;
#print $inhalt;
}
my $zeiger = new XML::Parser ();
$zeiger-setHandlers (Start = \anfang,End = \ende,Char=\inhalt );
$zeiger-parsefile (Datei.osm);
Gruß
Sven
Gruß Jan :-)
BTW: Bitte lass doch den Inflationären Gebrauch von Simlies, das führt dazu
das ich dich manchmal nicht ernst nehme.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Perl-Zugriff auf OSM-Daten
Jan Tappenbeck schrieb: Hi ! ich versuche langsam den Einstieg in Perl. Da das OSM-Datenformat xml-basiert ist suche ich ein einfaches Einsteigerbeispiel für die Datenfilterung einer Datei. Z.B. alle shop=butcher in der Datei. Hat einer von Euch ein solches zur Hand und kann es mir zur Verfügung stellen ? Gary68 hat einige Perl-Module für OSM entwickelt - http://wiki.openstreetmap.org/wiki/User:Gary68 vielleicht erspart dir das ja Arbeit. lg roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Stellungnahme RVR und Stadt Dortmund
Hallo Community, am 17.09.2008 haben Frank Jäger vom KRZ Minden-Ravensberg/Lippe und ich das Projekt OSM beim Regionalverband Ruhr (RVR) und Vertretern der eingebundenen Kommunen präsentiert. Nun liegt uns eine Stellungnahme vor [1]. Kurzer Zitat von unserem Ansprechpartner Herrn Terwyen: Das Thema OpenStreetMap ist bei den Kommunen im Sommer 2008 hoch gekocht und heute interessiert es niemanden mehr. Dies liegt auch daran, dass sich die OpenStreetMap Daten mit großer Dynamik weiterentwickeln und die Kommunen sehen dass die Entwicklung nicht aufzuhalten ist. Die Kommunen wollen daher zukünftig ihre eigenen Daten besser aufbereiten und vermarkten. Die Formulierungen sind durch die Vielzahl der Beteiligten etwas bürokratisch geworden. Entscheidend für sie ist der Inhalt des dritten Spiegelstrichs. [...] Alle Anfragen, die an Kommunen im RVR gestellt werden, laden zentral bei der Stadt Dortmund. Hier haben Markus Schäfer und ich am 08.09.2008 eine Information beim Vermessungs- und Katasteramt der Stadt Dortmund gehalten. Auch hier liegt uns eine Stellungnahme vor [2]. Zur generellen Übersicht der Kommunikation mit Akteuren habe ich die Cooperation-Seite [3] ins Deutsche Übersetze [4]. Vielleicht können wir die Anfragen hier ein wenig strukturieren oder koordinieren und eine Art Methodensammlung für die Kommunikation aufbauen (Markus?). Persönliche Anmerkung: Unsere Ansprechpartner beim RVR und bei der Stadt Dortmund waren von Anfang sehr freundlich und offen eingestellt - sowohl via E-Mail als auch via Telefon und bei den Treffen. Leider wurden die Mitarbeiter vorallem im Forum teilweise stark kritisiert (Suche nach Amtsfritze). Ich kann sowas nicht gut heißen, da diese Leute ihren Job tun!!! Viele von ihnen mappen selbst privat für OSM, obwohl sie die ganze Woche nichts anderes die kommunale Seite tun ... Viele Grüße Tobias Referenzen: [1] http://wiki.openstreetmap.org/wiki/DE:Kommunikation/RVR [2] http://wiki.openstreetmap.org/wiki/DE:Kommunikation/Stadt_Dortmund [3] http://wiki.openstreetmap.org/wiki/Cooperation [4] http://wiki.openstreetmap.org/wiki/DE:Kommunikation ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Strassen-Abgleich mit TMC-Karte
Hallo, ich habe ein Werkzeug(1) geschrieben mit dem man die TMC LocationCodeListe eines Landes, z.B. Deutschlands (2) parsen und die Segmente zu einer OSM- Datei zusammenbauen kann. Das Ergebniss ist eine Deutschland-Karte mit allen Autobahnen, Bundesstrassen, BAB-Tankstellen, ... diese Karte kann man problemlos in einen eigenen Layer in JOSM laden und damit vergleich ob uns irgendwo noch Daten fehlen. (Datenübernahme NICHT erlaubt aber gegen ein einfaches Nachsehen, und Aufschreiben was in der LCL ist und bei uns fehlt hat ja keiner was.) Wäre eine super Gelegenheit mal zu sehen, ob unser Bundesstrassen -Netz vollständig ist. Und das natürlich nicht nur für Deutschland sondern für jedes Land Europas, für das wir die LCL bekommen. (Italien z.B. schwirrt irgendwo rum.) Ich habe selber schon bei einer Stichprobe 2 fehlende Autobahn-Tankstellen gefunden. Ich kann mir gut vorstellen, dass uns sogar noch komplette, kleinere Bundesstrassen fehlen. Tankstellen und ref-Tags sicherlich. Wer wäre bereit sich mit der erzeugten OSM-Datei mal hinzusetzen und die mit unserem Stand zu vergleichen? Die OSM-Datei hat gerade mal 15MB unkomprimiert, komprimiert 914KB. Marcus (1) wird heute abend nach SVN-Checkin auf https://apps.sourceforge.net/mediawiki/travelingsales/index.php?title=Plugin/TrafficMessageChannel#Status verlinkt (2) http://www.bast.de/cln_007/nn_213316/DE/Aufgaben/abteilung-f/referat-f4/Location-Code-List/location-code-list-nutzungsbedingungen.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fotos für MapFeatures?
Hallo Community, jetzt wo das Wetter besser wird, will ich ein paar Fotos machen und mit GeoTags versehen. Meint ihr, dass man diese Fotos vielleicht auch für die MapFeatures verwenden kann, um so Einsteigern das Tagging zu vereinfachen? Die bisherigen MapFeatures haben ja nur wenige Fotos ... so könnte man es z.B. einfacher machen, einen festen Beton- von einem umklappbaren Metall-Poller zu unterscheiden, ohne dass man sich erst durchlesen, übersetzen oder etwas erklären muss. Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Tobias Wendorff schrieb: Hallo Community, am 17.09.2008 haben Frank Jäger vom KRZ Minden-Ravensberg/Lippe und ich das Projekt OSM beim Regionalverband Ruhr (RVR) und Vertretern der eingebundenen Kommunen präsentiert. Nun liegt uns eine Stellungnahme vor [1] Hallo Tobias, danke für die Mitteilung. Was heißt das jetzt für uns in der Kürze ? Ich lese daraus, dass ich die Bilder vom WMS-Server RVR benutzen kann. Ich kann: 1.) meine tracks - strassen - mit den Daten abgleichen. 2.) meine gps-daten - Häuser und Gebäude - mit denen vom RVR vergleichen und eventuell durch nachzeichnen korrigieren. 3.) meine Aufzeichnungen landuse - mit den Bildern vom RVR abstimmen und eventuell ändern. Ich darf nicht: Die Bilder vom RVR abzeichnen ? Habe ich alles richtig verstanden ? Grüsse Willi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Hallo Willi, Willi Rehfeld schrieb: danke für die Mitteilung. Was heißt das jetzt für uns in der Kürze ? ich habe bewusst keine Aussage hierzu betroffen, da wir das lieber in der Menge diskutieren sollten. Ich bin da teilweise zu ... ihr wisst. 1.) meine tracks - strassen - mit den Daten abgleichen. Yepp, aber dazu braucht man ja keine Genehmigung :-) 2.) meine gps-daten - Häuser und Gebäude - mit denen vom RVR vergleichen und eventuell durch nachzeichnen korrigieren. Genau, so wie ich es verstehe, dürfen wir die Daten korrigieren. Kommt halt darauf an, wie man zu amtlichen Daten und deren Genauigkeit steht :-) 3.) meine Aufzeichnungen landuse - mit den Bildern vom RVR abstimmen und eventuell ändern. So verstehe ich es auch. Ich darf nicht: Die Bilder vom RVR abzeichnen ? Genau. Dortmund lässt ja eine Option offen (Kauf von Material), aber der RVR ist gegen das Abdigitalisieren. Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
Hallo Astrid, Astrid Müller schrieb: Bordsteine über den Schlüssel border zu taggen finde ich eine gute Idee und besser als mit dem Tag Sloped_curb=yes. Somit ist der Schlüssel allgemeiner gehalten und man hat die Möglichkeit einzelne Werte wie Höhe und Breite hinzu zu fügen. Bisher wurden Bordsteinhöhen auch noch nicht getaggt? nein, aber ich habe auch schon erwogen dies mit einem Zollstock zu tun. Ist für vielerlei Dinge nützlich, z.B. Rollstühl-Navi oder Straßenreinigung. Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fotos für MapFeatures?
Am 31. März 2009 15:57 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Hallo Community, jetzt wo das Wetter besser wird, will ich ein paar Fotos machen und mit GeoTags versehen. Meint ihr, dass man diese Fotos vielleicht auch für die MapFeatures verwenden kann, um so Einsteigern das Tagging zu vereinfachen? Die bisherigen MapFeatures haben ja nur wenige Fotos ... so könnte man es z.B. einfacher machen, einen festen Beton- von einem umklappbaren Metall-Poller zu unterscheiden, ohne dass man sich erst durchlesen, übersetzen oder etwas erklären muss. ja, unbedingt. Ich halte das für eine gute Idee. Ist im Prinzip ja auch Konsens und auf der features Seite vorbereitet, fehlen nur noch Bilder, die man aus meiner Sicht gern ergänzen kann. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Tobias Wendorff schrieb: Hallo Willi, Willi Rehfeld schrieb: Ich darf nicht: Die Bilder vom RVR abzeichnen ? Genau. Dortmund lässt ja eine Option offen (Kauf von Material), aber der RVR ist gegen das Abdigitalisieren. Macht es einen Unterschied, ob ich jetzt blind ein Landuse zeichne und dann den WMS-Layer anschalte und es zurecht ziehe und schiebe oder ob ich es gleich dem WMS-Bild folgend zeichne? Für mich ist das eine sehr schwammige Lösung, vermutlich von ihnen absichtlich so gemacht, um uns das Abzeichnen zu ermöglichen, aber nicht irgendwie im Bezug auf andere Kartenanbieter in Bedrängnis zu geraten. Außerdem widerspricht sich das irgendwie, in dem PDF-Dokument heißt es ja zuerst: Daten für die Erstherstellung und die Fortführung des OSM-Datenbestandes auszuwerten Erstherstellung heißt für mich weißer Screen, dann WMS-Bild und los. Danach wird dann offenbar nochmal die Verwendung eines Webdienstes eingeschränkt, mit dem Stadtplan darf ich aber anscheinend etwas mehr machen. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fotos für MapFeatures?
Tobias Wendorff schrieb: Hallo Community, jetzt wo das Wetter besser wird, will ich ein paar Fotos machen und mit GeoTags versehen. Meint ihr, dass man diese Fotos vielleicht auch für die MapFeatures verwenden kann, um so Einsteigern das Tagging zu vereinfachen? Ja, klar. Vor langer Zeit von mir auch mal hier angestoßen: http://wiki.openstreetmap.org/wiki/User:John07/fehlende_bilder (veraltet !) Es hat damals nicht wirklich Spaß gemacht, da das Wiki ständig überlastet war und kein Bildupload möglich war. Außerdem ist das mehr Arbeit als man denkt. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Hallo Tobias. Am Dienstag 31 März 2009 15:16:46 schrieb Tobias Wendorff: [...] Entscheidend für sie ist der Inhalt des dritten Spiegelstrichs. [...] Nett. Also es ist etwas politisch formuliert, es steht viel drin aber wenig konkrete Aussage. Aber ich nehme für mich daraus die Erkenntnis mit, dass das Korrigieren von OSM-Daten anhand von Luftbildern nach Ansicht des RVR erlaubt ist. Und so wie das formuliert ist, würde ich sagen ist das zwar die Meinung des RVR, bezieht sich aber eigentlich auf alle Luftbilder, auch von anderen Quellen. Für mich bedeutet dies (ich hab mit dem RVR hier in Ba-Wü nichts am Hut), dass ich Objekte, deren Lage ich Pi mal Daumen weiß und/oder durch ein GPS-Signal grob verorten kann zusätzlich mit Hilfe von Luftbildern präziser eintragen kann. Hier wären das z.B. die Bilder des LVA Ba-Wü, die zwar nicht zum Abzeichnen freigegeben werden, aber gute Dienste leisten bei der Einschätzung ob die GPS-gemessenen Daten plausibel sind. Zukünftig kann ich diese Bilder also zusätzlich als Interpolationshilfe nehmen um ungenau gemessene Daten danach zu korrigieren. So verstehe ich zumindest die Stellungnahme des RVR. Gruß, Bernd -- Das Licht am Ende des Tunnels kann auch ein entgegenkommender Zug sein. - Gregor Gysi signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Jonas Krückel (John07) schrieb: Macht es einen Unterschied, ob ich jetzt blind ein Landuse zeichne und dann den WMS-Layer anschalte und es zurecht ziehe und schiebe oder ob ich es gleich dem WMS-Bild folgend zeichne? Nachweisen kann es Dir keiner ... aber Herr Terwyen meinte dazu: Ich weiß, dass viele OSM-er Fremddaten platt abdigitalisieren. Das hehre Bild vom idealistischem GPS-Tracker und Rechercheur stimmt nicht immer. Er kann es ja an den LOG-Daten sehen und dann mit den Bereichen vergleichen. Erstherstellung heißt für mich weißer Screen, dann WMS-Bild und los. Danach wird dann offenbar nochmal die Verwendung eines Webdienstes eingeschränkt, mit dem Stadtplan darf ich aber anscheinend etwas mehr machen. Der Stadtplan wird ja auch als Web-Dienst angeboten... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Hallo Bernd, Bernd Wurst schrieb: Für mich bedeutet dies (ich hab mit dem RVR hier in Ba-Wü nichts am Hut), hey, nicht so negativ denken - ich habe ja auch in der Oberpfalz mitgezeichnet :-) Zukünftig kann ich diese Bilder also zusätzlich als Interpolationshilfe nehmen um ungenau gemessene Daten danach zu korrigieren. So verstehe ich zumindest die Stellungnahme des RVR. +1 Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Tobias Wendorff schrieb: Jonas Krückel (John07) schrieb: Macht es einen Unterschied, ob ich jetzt blind ein Landuse zeichne und dann den WMS-Layer anschalte und es zurecht ziehe und schiebe oder ob ich es gleich dem WMS-Bild folgend zeichne? Nachweisen kann es Dir keiner ... aber Herr Terwyen meinte dazu: Ich weiß, dass viele OSM-er Fremddaten platt abdigitalisieren. Das hehre Bild vom idealistischem GPS-Tracker und Rechercheur stimmt nicht immer. Warum haben sie dann keine vernünftige Formulierung gewählt? Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Naturschutzgebiete in Mapnik
Moin ! es werden langsam immer mehr NSG erfaßt und Mapnik stellt diese in den Zoomstufen bis 12 als grüne Flächen dar mit einem entsprechenden Text. Wenn ich mir überlege ich lade die NSG von Lübeck hoch, dann ist die Karte im Eimer - erst in kleineren Zoomstufen wird der Rand nur noch dargestellt. Beispiel bei Flensburg: http://www.openstreetmap.de/karte.html?zoom=10lat=54.5727lon=9.77545layers=B0 Spanien: http://www.openstreetmap.de/karte.html?zoom=7lat=40.31022lon=-3.83524layers=B0 Kann man irgendwie Einfluss daraufnehmen, dass diese Darstellung anders erfolgt? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
On Tue, 31 Mar 2009, Tobias Wendorff wrote: Er kann es ja an den LOG-Daten sehen und dann mit den Bereichen vergleichen. Wie? Ich lade z.B. keine Tracks hoch. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Dirk Stöcker schrieb: Er kann es ja an den LOG-Daten sehen und dann mit den Bereichen vergleichen. Wie? Ich lade z.B. keine Tracks hoch. Meine Einschätzung: Wenn die Wege wirklich exakt übereinander liegen und z.B. Generalisierungen aus den Karten übernommen wurden (vielleicht auch Easter-Eggs) kann man schon seine Rückschlüsse daraus ziehen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
On Tue, 31 Mar 2009, Tobias Wendorff wrote: Dirk Stöcker schrieb: Er kann es ja an den LOG-Daten sehen und dann mit den Bereichen vergleichen. Wie? Ich lade z.B. keine Tracks hoch. Meine Einschätzung: Wenn die Wege wirklich exakt übereinander liegen und z.B. Generalisierungen aus den Karten übernommen wurden (vielleicht auch Easter-Eggs) kann man schon seine Rückschlüsse daraus ziehen. Wennn ich sowas machen würde, dann würde ich Stützmessungen nehmen und nur verdichten. Da ich mich somit vor Ort auskenne kann keiner entscheiden, ob alles gemessen ist oder nicht. Aber ich mache sowas ja nicht :-) Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Dirk Stöcker schrieb: Wennn ich sowas machen würde, dann würde ich Stützmessungen nehmen und nur verdichten. Da ich mich somit vor Ort auskenne kann keiner entscheiden, ob alles gemessen ist oder nicht. Aber ich mache sowas ja nicht :-) Aber manche tun es. Jetzt mal ernst: Herr Terwyen ist echt freundlich und findet OSM gut. Er würde uns sowas nicht an den Kopf werfen, wenn es nicht der Wahrheit entspräche. Die Mehrzahl sieht uns halt als Konkurrenz an ... das war zu erwarten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fotos für MapFeatures?
Jonas Krückel (John07) schrieb: http://wiki.openstreetmap.org/wiki/User:John07/fehlende_bilder (veraltet !) Militärgelände wirst Du ein Deutschland wohl nicht bekommen :-) Vielleicht wäre es auch teilweise besser, die Waren zu fotografieren, als den Laden von außen: Bäckerei, Bücherei, etc. Vulkan ... da müsste ich noch Fotos aus Italien haben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Naturschutzgebiete in Mapnik
Am 31. März 2009 16:55 schrieb Jan Tappenbeck o...@tappenbeck.net: es werden langsam immer mehr NSG erfaßt und Mapnik stellt diese in den Zoomstufen bis 12 als grüne Flächen dar mit einem entsprechenden Text. Wenn ich mir überlege ich lade die NSG von Lübeck hoch, dann ist die Karte im Eimer - erst in kleineren Zoomstufen wird der Rand nur noch dargestellt. Beispiel bei Flensburg: http://www.openstreetmap.de/karte.html?zoom=10lat=54.5727lon=9.77545layers=B0 Spanien: http://www.openstreetmap.de/karte.html?zoom=7lat=40.31022lon=-3.83524layers=B0 Kann man irgendwie Einfluss daraufnehmen, dass diese Darstellung anders erfolgt? im trac von OSM unter mapnik und tilesathome ein entsprechendes Ticket machen, für ti...@home kannst Du auch gleich Patches einreichen, dann sollte es schneller gehen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Experimentelles neues 'TagWatch' bzw. Tagstatistiken
Hi, planst du eigentl. auch einen OSM-XAPI Link? Wäre sehr nützlich um Tags zu korrigieren bzw. sie sich mal im Editor anzuschaun. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Experimentelles neues 'TagWatch' bzw. Tagstatistiken
Moin, planst du eigentl. auch einen OSM-XAPI Link? Wäre sehr nützlich um Tags zu korrigieren bzw. sie sich mal im Editor anzuschaun. jetzt wo Du es sagstich weiß nicht warum ich nicht selbst auf die Idee gekommen bin. Ist ne weile her, dass ich mich damit beschäftigt habe, ich weiß z.B. nicht was es mit diesem ROMA- und TRAPI-Kram usw. auf sich hat. Das letzte mal, dass ich OSM-XAPI nutzen wollte ging das entweder nicht oder die Daten waren veraltet aber das ist schon Monate her. Ich schreibe mir das auf und werde das in irgendeiner Form einbauen. Danke für den Hinweis. Abgesehen davon habe ich in den letzten beiden Tagen hauptsächlich Arbeit im Hintergrund gemacht. Bis grad eben habe ich weiter an den täglichen Datenupdates gearbeitet, das werde ich morgen weiter fortsetzen. Ansonsten probiere ich die Über-Seite regelmäßig mit News zu aktualisieren (auch wenn das nicht der ideale Platz ist...das wird die Zeit richten ;-) ) und schreibe auch hier nochmal bei interessanten Neuerungen. Gruß, Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Experimentelles neues 'TagWatch' bzw. Tagstatistiken
Lars Francke schrieb: Moin, planst du eigentl. auch einen OSM-XAPI Link? Wäre sehr nützlich um Tags zu korrigieren bzw. sie sich mal im Editor anzuschaun. jetzt wo Du es sagstich weiß nicht warum ich nicht selbst auf die Idee gekommen bin. Ist ne weile her, dass ich mich damit beschäftigt habe, ich weiß z.B. nicht was es mit diesem ROMA- und TRAPI-Kram usw. auf sich hat. Das letzte mal, dass ich OSM-XAPI nutzen wollte ging das entweder nicht oder die Daten waren veraltet aber das ist schon Monate her. Ich schreibe mir das auf und werde das in irgendeiner Form einbauen. Danke für den Hinweis. Gerne, hatte schon befürchtet, ich hab es nur übersehen :-) Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Handwerk, Industrie, Wirtschaft und Verwaltung
Martin Koppenhoefer schrieb: wie unterscheidest Du denn Wirtschaftsunternehmen und Industrie? Und wie wird Handwerk von den beiden abgegrenzt? Nicht zu vergessen, dass ordentliche Handwerker eine ziemlich deutsche Sache sind und sich entsprechend schwer internationalisieren lassen. Das ist zwei kein Grund, sowas nicht in OSM aufnehmen zu wollen. Es macht die Sache aber nicht einfacher. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nutzung der TMC Locationcode-Liste in OSM dur ch Bundesanstalt für Straßenwesen ERLAUBT!!!
Good news everyone! Wir dürfen: * Bestehender Punkte unserer frei verfügbaren Karte mit ihrem jeweiligen Locationcode taggen. * POIs (Tankstellen, Strassennamen,..) ais der TMC LocationCodeList zur Überprüfung der Vollständigkeit unserer Karte nutzen und ggf. Namen und Orte übernahmen. Vorgehen: # Sinnvollerweise sollten wir versuchen mit der vorliegenden LCL für Deutschland einen guten Arbeitsablauf für den späteren Import vom Rest von Europa zu etablieren. # Ich versuche jetzt erstmal mehr über die Arten, wie die LocationCodes in TMC-Nachrichten genutzt werden herauszufinden # dann werde ich wohl Hilfe für ein Tagging-Schema für TMC-Codes brauche. # auf http://apps.sourceforge.net/mediawiki/travelingsales/index.php?title=Plugin/TrafficMessageChannel#Convert_TMC_LoctionCodeList_to_OpenStreetMap steht schon ein Tool bereit, was eine TMC -LCL in OpenStreetMap umwandelt. Was wir brauchen ist aber eine Möglichkeit TMC-Nachrichten, welche sich auf die Punkte, Segmente, Wege, Gebiete, Richtungen und deren Verhältniss zueinander beziehen nutzbar auf unsere (wesentlich detailierteren) OSM-Daten abzubilden. Ich könnte momentan jedes Bisschen Information bezüglich dem Aufbau von TMC-Nachrichten und deren Einbettung in NMEA gebrauchen. Marcus == Sehr geehrter Herr Wolschon, vielen Dank für Ihre Anfrage zur Verwendung der Location Code List. Die Nutzung der LCL für Ihre Produkte und Anwendungen, wie in Frage 1,3 und 4 von Ihnen geschildert, ist zulässig, da Sie diese auch im Verwendungszweck angegeben haben. Von einer Veröffentlichung der LCL im originären Format und Umfang bitte ich jedoch abzusehen, ebenso von der Veröffentlichung der Dokumente, die Ihnen die BASt zusammen mit der LCL8.0 zugesandt hat. Interessenten der LCL können Sie auf die Bestellmöglichkeit bei der BASt hinweisen. Ihre 2. Frage zur Veröffentlichung einer ausführlichen Dokumentation des TMC-Exchange-Format, kann ich Ihnen nicht beantworten: Ich vermute, dass Sie mit TMC-Exchange-Format die vom TMC-Forum seinerzeit erstellten Dokumente und Standards für TMC meinen. Hier müssen Sie klären, inwieweit Urheberrechte bestehen. Eventuell wird man Ihnen bei TISA (www.tisa.org) weiterhelfen können, welche heute für alle Standardisierungsfragen in TMC zuständig ist. Die Veröffentlichung eines ganzen Standardpapieres, wie Sie es über DIN beziehen können, ist vermutlich auch nicht zulässig. Wenden Sie sich in dieser Frage eventuell auch an DIN e.V. bzw. Beuth-Verlag. Bei eigenen Dokumententationen zur LCL mit Zitaten und Auszügen bei entsprechenden Quellenangaben raten ich, im Zweifelsfall die entsprechenden Stellen anzuschreiben. Für Rückfragen stehe ich Ihnen gern zur Verfügung. Mit freundlichen Grüßen Im Auftrag Jessica Kleine Bundesanstalt für Straßenwesen Referat F4 Kooperative Verkehrs- und Fahrerassistenzsysteme Brüderstraße 53 51427 Bergisch Gladbach Telefon: 02204/43 644 Fax: 02204/43 676 E-Mail: kle...@bast.de -Ursprüngliche Nachricht- Von: Marcus Wolschon [mailto:mar...@wolschon.biz] Gesendet: Montag, 30. März 2009 14:41 An: BAST, LCL Betreff: Übernahme von Daten aus oder Referenzietung auf die Location Code List, Version 8.0 Guten Tag, mein Name ist Marcus Wolschon und ich entwickle das Navigationssystem Traveling Salesman für die Nutzung der freien Strassenkarte OpenStreetmap (http://openstreetmap.org) Ich würde gerne Anfragen ob einige der folgenden Nutzungen der deutschen Location Code List, Version 8.0 zugelassen werden: für mein Navigationssystem: * Einbettung einer aus der LCL generierten Tabelle in einem anwendunge- spezifischem Binärformat (also keine Veröffentlichung der original .dat oder CSV) in mein quellenoffenes Navigationsystem und kostenlose Bereitstellung dieses Navis für Nutzer. * Ausführliche Dokumentation des TMC-Exchange-Format zur Einbindung der LCL anderer Länger zu einer späteren Zeit. für unsere Karte: * Nutzung der POIs (Tankstellen, Strassennamen,..) zur Überprüfung der Vollständigkeit unserer Karte und ggf. Übernahmen von Namen und Orten. * Attributierung bestehender Punkte unserer frei verfügbaren Karte mit ihrem jeweiligen Locationcode. Mit freundlichen Grüssen, Marcus Wolschon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Willi Rehfeld schrieb: 1.) meine tracks - strassen - mit den Daten abgleichen. 2.) meine gps-daten - Häuser und Gebäude - mit denen vom RVR vergleichen und eventuell durch nachzeichnen korrigieren. 3.) meine Aufzeichnungen landuse - mit den Bildern vom RVR abstimmen und eventuell ändern. Ich mappe in Herdecke (Ruhrgebiet Südost). Beruflich bedingt habe ich eine weit überdurchschnittliche Ortskenntnis sowohl der allermeisten Straßen des Stadtgebietes als auch - zumindest stellenweise - der Pfade und Wanderwege einschließlich der Topographie mit Landnutzung, Hochspannungsleitungen, Bauernhöfen und größeren Gebäuden. Für mich ist es, wenn ich hier mappe, wenig sinnvoll, Straßen, deren Verlauf ich ohne GPS-Track aus dem Kopf auf 20-30 m genau in die Karte malen kann, pro forma mit meinem etrex abzulaufen. Ebenso verhält es sich mit Gebäuden - ich weiß, zwischen welchen Straßen die Firma Siepmann Landhandel liegt, wie viele Gebäude ungefähr welcher Größe sich wo auf dem Firmengelände befinden etc. Will sagen: wenn ich aus dem Kopf mappe, dürfte ich anhand des RVR-Luftbildes diese Gedächtnisprotokolle korrigieren. Oder verstehe ich etwas falsch? Ich frage mich dann weiter, ob der Schritt, die Sachen, die ich kenne, direkt anhand des Luftbildes einzutragen, verbotener ist. Ich rede tatsächlich von Straßen, Wegen, Gewerbegebieten, Firmen, Lagerhallen, Rapsäckern, die ich aus eigener Anschauung kenne - derzeit mappe ich nur in mir bestens bekanntem Gebiet. Also ein Gebäude, dessen Lage ich schätzen kann, im Luftbild zu suchen, zu zeichnen und es mit dem Namen Grundschule Schraberg zu versehen, den ich nicht aus dem Luftbild, sondern aus meinem Kopf nehme. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nutzung der TMC Locationcode-Liste in OSM dur ch Bundesanstalt für Straßenwesen ERLAUBT!!!
Ich habe eine Wiki-Seite unter http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany für dan Import der TMC -Daten angelegt. Da läßt sich alles dann mal dokumentieren. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Handwerk, Industrie, Wirtschaft und Verwaltung
Hallo zusammen, Gedanken über die Unterscheidung zwischen Handwerk und Industrie habe ich mir noch nicht gemacht. Die Übergänge werden fließend sein und das werden die OSM-Mapper später schon hinkriegen. Wichtig ist mir nur, das wir erstmal über einen Grundstock an Tagging Features für den Bereich Wirtschaft mit Produktion, Dienstleistung, Verwaltung nachdenken. Darauf gestoßen bin ich als ich Handwerksbetriebe in meiner Umgebung erfassen wollte. Wie tagge ich dann den Schreiner, Drucker, Maler, Dachdecker, Schornsteinfeger? shop=* mag gehen, trifft aber nicht genau. besser wäre vielleicht trade=carpenter trade=printer etc. oder craft=mason craft= Und was besseres habe ich noch nicht gefunden. Und wie die Industriebetriebe die sich hier angesiedelt haben? Den Autoproduzenten, die große Werft, die Raffinerie, die Brauerei? industry=car industry=ship oder industry=wharft industry=brewerey oder industry=beer Wobei ich lieber das Getränk von der Hausbrauerei genieße, also von trade=brewer. Und dann die Verwaltungsgebäude? Die Verwaltung des Versicherungsunternehmens, das Hauptquartier des Telekommunikationsunternehmens, die Filiale eines Softwareunternehmens? office=inssurance office=telecommunication function=headquarter Nur mal so als Anfang für weitere Gedanken. Bis bald Harald Schwarz black_bike Am Tuesday 31 March 2009 01:45:06 schrieb Martin Koppenhoefer: Am 30. März 2009 22:18 schrieb Harald Schwarz harald.malte.schw...@gmx.de: Hallo zusammen, Verkehr, Freizeit, Kultur, Bildung und Religion sind bei den Map Features schon gut abgedeckt. Bisher habe ich aber nur sehr wenig zu den Bereichen Handwerk, Industrie, Verwaltung gefunden. Auch bei den Proposed Features bin ich noch nicht auf diese Kategorien gestoßen. Was mir vorschwebt ist soetwas wie (später natürlich in OSM-English): Zum Handwerk: .. Und zur Industrie: .. Und zur Verwaltung, Wirtschaftsunternehmen: wie unterscheidest Du denn Wirtschaftsunternehmen und Industrie? Und wie wird Handwerk von den beiden abgegrenzt? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Jonas Krückel (John07) schrieb: Tobias Wendorff schrieb: Jonas Krückel (John07) schrieb: Macht es einen Unterschied, ob ich jetzt blind ein Landuse zeichne und dann den WMS-Layer anschalte und es zurecht ziehe und schiebe oder ob ich es gleich dem WMS-Bild folgend zeichne? Nachweisen kann es Dir keiner ... aber Herr Terwyen meinte dazu: Ich weiß, dass viele OSM-er Fremddaten platt abdigitalisieren. Das hehre Bild vom idealistischem GPS-Tracker und Rechercheur stimmt nicht immer. Warum haben sie dann keine vernünftige Formulierung gewählt? Gruß Jonas Hallo, die Formulierungen sind ein politischer Kompromiss um den wirklich gerungen wurde. Sonst wäre das Protokoll ja gleich nach der Sitzung fertig gewesen. Der RVR ist ein Verband. Mitglieder sind viele Kommunen und jede hat eigene Ziele und Auffassungen. Die Meinungen waren durchaus kontrovers, nicht jeder findet OSM gut. Anfangs hieß es sogar, eine einzelne Kommune drohe mit dem Austritt, wenn Daten abgegeben würden. Vor dem Hintergrund ist das Ergebnis doch erfreulich. Den Abgleich der eigenen Daten mit dem Luftbild halte ich für eine nützliche Sache um die Lagegenauigkeit zu verbessern oder großflächige Objekte (Landuse) besser abzugrenzen, die sich schlecht umlaufen lassen. Ich halte allerdings nichts davon, fertige (Stadt-) Pläne dafür zu verwenden. Man kennt nicht die Aktualität und man würde jeden Fehler übernehmen. Man weiß z.B. nicht ob im Rahmen der Generalisierung ein Objekt verschoben wurde, damit ein nebenstehender Text besser lesbar ist. In einem Kartenwerk ist das manchmal sinnvoll weil es die Lesbarkeit verbessert, aber wir erfassen erst einmal Daten. -- Frank Jäger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Tobias Wendorff schrieb: Die Mehrzahl sieht uns halt als Konkurrenz an ... das war zu erwarten. Das ist doch eine gewaltige Auszeichnung. Konkurrent ist nur der der besser ist oder zumindest besser zu werden droht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Thomas Reincke schrieb: Tobias Wendorff schrieb: Die Mehrzahl sieht uns halt als Konkurrenz an ... das war zu erwarten. Das ist doch eine gewaltige Auszeichnung. Konkurrent ist nur der der besser ist oder zumindest besser zu werden droht. Naja, ich finds eine komische Ansicht. Imo sind das doch staatliche Institutionen und daher vom Bürger erstmal durch Steuergelder finanziert. Wenn sie jetzt den eigenen Bürger als Konkurrenz sehen, ist das etwas seltsam. Vermutlich sagen sie nun, dass wir ja auch kommerziell genutzt werden und sie dann indirekt über uns kostenlos Daten an Unternehmen geben würden. Aber selbst das sehe ich nicht als Argument, Unternehmen sind ja auch Teil des Staates (zahlen normalerweise Steueren, beschäftigen Bürger etc.) Ich sehe sie übrigens nicht als Konkurrenz, sondern als kleine Institutionen, die uns helfen könnten, aber das nicht tun. Früher oder später werden sie eh von OSM überholt und sind höchstens noch für akurate Daten notwendig (ich weiß nicht wie groß der Markt dafür ist, aber vermutlich lange nicht so groß wie der restliche Markt). Gruß Jonas P.S. Über negative Nebenwirkungen von Importen und Luftbildern will ich ein ander mal reden ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mikro-Wohngebiete oder Gärten?
Bernd Wurst schrieb: Es muss doch die Frage gestattet sein, was du mit deinem Tagging aussagen willst. Es ist absehbar, dass irgendwann alle Gebäude einzeln gemapped sind. Dass da also mehrere Gebäude stehen, sieht man dann unmittelbar an den mehreren Gebäuden, die da eingezeichnet sind. Da braucht man nicht noch grobmotorisch ne Fläche drum herum zeichnen. Sobald ein Wohn- oder Industriegebiet als solches bekannt ist (bzw. so genannt werden kann) und im Idealfall auch einen expliziten Namen hat, ist alles prima, dann zeichnet man das Gebiet ein und hat eine super Information in den Daten, nämlich dass das Wohngebiet sowieso eben dort ist sowie auch die und die Größe und Ausmaße hat. Um den Kontext klar zu stellen: Fast alle Flächen innerorts lassen sich spontan in Wohn-, Gewerbe-, Industrie- oder Mischgebiet einteilen, was man mit den etablierten Tags wunderbar darstellen kann. Daher soll es hier ja um die weniger offensichtlichen Fälle gehen. Einfach nur zu sagen: Da stehen = 2 Gebäude, manche zum drin wohnen., da sehe ich irgendwie keinen wirklichen Nutzen, den man nicht auch einfach aus dem offensichtlichen Umfeld erkennen könnte. Da wäre ein type=residential oder sowas in der Art an einem Gebäude besser geeignet. Fakt ist dass in D (und schon gar nicht weltweit) noch lange nicht alle Besiedlungen erfasst sind nicht mal die Orstnamen die dann scheinbar zusammenhangslos irgendwo in der Pampa stehen. Daher halte ich es für sehr sinnvoll alles was aus einer Gruppe von Gebäuden besteht mit landuse zu erfassen. Im ersten Schritt gerne grob umrissen mit landuse=residential wie es einige schon seit jeher machen um irgendwann in absehbarer Zeit mal sagen zu können es sind alle Besiedlungen/Bebauungen (die über ein einzelnes Gebäude hinausgehen) erfasst. Dann wird als Folge auch bald jeder Ort per OSM erreichbar sein - ein wichtiges Argument um auch kommerzielle Anwednungs/Navianbieter dazu zu bewegen OSM-Karten zu unterstützen.Das bringt mehr als sich hinzustellen und zu sagen dass sich der landuse-tag erübrigt wenn erstmal alles Gebäude erfasst sind - was noch viele Jahre dauern wird. Alle Siedlungen in D per OSM erreichbar zu machen wäre dagegen ein Ziel dass gut bis Ende des Jahres erreichbar sein sollte. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mikro-Wohngebiete oder Gärten?
Martin Koppenhoefer schrieb: Nur weil man einzelne Gebäude mappt muss man m.E: auf die Flächen für das ganze Gebiet nicht verzichten - aber bitte nicht grobmotorisch ;-) Das ist besser wie gar nichts an den Stellen wo sonst noch nicht mal der Ortsname geschweige den Strassen zu finden sind. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Handwerk, Industrie, Wirtschaft und Verwaltung
Harald Schwarz schrieb: Hallo zusammen, Verkehr, Freizeit, Kultur, Bildung und Religion sind bei den Map Features schon gut abgedeckt. Bisher habe ich aber nur sehr wenig zu den Bereichen Handwerk, Industrie, Verwaltung gefunden. Auch bei den Proposed Features bin ich noch nicht auf diese Kategorien gestoßen. Das sollte meiner Meinung nach eigentlich ehr aus der OSM-Datenbank draussen bleiben und in einer separaten POI-Datenbank erfasst werden - schon alleine um das Thema Datenschutz aus OSM herauszuhalten. Könnte mir vorstellen dass es da Probleme geben kann wenn da plötzlich auch mehr oder weniger Privatadressen auf den Karten auftauchen mit denen der Besiter nicht einverstanden ist. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Darstellung von highway=road in Mapnik ändern?
Fabian Schmidt schrieb: Am 23.03.09 schrieb Tobias Hägele: Deshalb mein Wunsch nach einer anderen Farbgebung. Möglichst so, dass jeder der zum ersten Mal osm.org aufruft und eine road sieht, sich zweimal überlegt, diesen Weg in seine Streckenplanung mit einzubeziehen. es liegt in der Farbe in der Nähe von living_streets und pedestrians, die auch nur bedingt zum durchfahren taugen, insofern passt es doch. Und es hebt sich deutlich von den in gut erfassten Gebieten zahlreichen klassifizierten Straßen ab. road kann aber auch genausogut eine Autobahn sein! Von daher passt es nicht! Vielleicht kann man ja fortlaufen unknown classification entlang der road rendern (anstelle des Strassennamens) - das hebt die Motivation den way richtig zu klassifizieren. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Darstellung von highway=road in Mapnik ändern?
Mario Salvini schrieb: ein highway=road hat ohne weitere Angaben genausowenig Aussage wie highway=path (Außer das ein Unterschied in den default-Restriction vorliegen kann. Ein highway=path ist z.B. eigentlich nix für Kraftfahrzeuge highway=road eigentlich aber schon) Das hat überhaupt nix mit Bug zu tun. Ein highway=path ohne weitere Angaben ist ja auch kein Bug. Die Idee von road war denjenigen die ständig einen GPS-Logger mit sich führen aber keine Zeit haben ihren Weg genauer zu spezifizieren dennoch die möglichkeit zu geben ihren Weg sichtbar in den OSM-Karten darstellen zu können. Da können auch Fähren, Autoreiszüge etc. dabei sein. Dummerweise hat das dazu geführt dass einige nur noch road eingetragen haben obwohl sie auf 1-2 Kategorien genau hätten eintragen können was es tatsächlich ist. path gibt da schon etwas mehr Informationen, insbesondere dass es keine höher qualifizierte Strasse sondern ehr ein Wald-und Wiesenweg ist. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Jonas Krückel (John07) schrieb: Naja, ich finds eine komische Ansicht. Imo sind das doch staatliche Institutionen und daher vom Bürger erstmal durch Steuergelder finanziert. Wenn sie jetzt den eigenen Bürger als Konkurrenz sehen, ist das etwas seltsam. Du vergisst einen Punkt: Zwar werden die Ausgaben durch die Steuergelder gedeckt, aber durch den Verkauf von Geodaten lässt sich auf jeder Ebene massiv Geld in die Kasse spielen. Auf der FOSSGIS habe ich mit einigen Leuten gesprochen. Bekannte Firmen zahlen da eben für die ALK-Daten eines Bundesland 7 Millionen Euro. Es ist ja keine Nullrechnung ... der Sozialstaat muss sich ja auch irgendwie finanzieren :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Tobias Wendorff schrieb: Jonas Krückel (John07) schrieb: Naja, ich finds eine komische Ansicht. Imo sind das doch staatliche Institutionen und daher vom Bürger erstmal durch Steuergelder finanziert. Wenn sie jetzt den eigenen Bürger als Konkurrenz sehen, ist das etwas seltsam. Du vergisst einen Punkt: Zwar werden die Ausgaben durch die Steuergelder gedeckt, aber durch den Verkauf von Geodaten lässt sich auf jeder Ebene massiv Geld in die Kasse spielen. Auf der FOSSGIS habe ich mit einigen Leuten gesprochen. Bekannte Firmen zahlen da eben für die ALK-Daten eines Bundesland 7 Millionen Euro. Es ist ja keine Nullrechnung ... der Sozialstaat muss sich ja auch irgendwie finanzieren :-) Ja, nun letztlich zahlt halt der Bürger dann wieder an die Firma für die Daten im Navi oder sonstwo. :-) Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Handwerk, Industrie, Wirtschaft und Verwaltung
Hallo Harald. Harald Schwarz wrote: Darauf gestoßen bin ich als ich Handwerksbetriebe in meiner Umgebung erfassen wollte. Wie tagge ich dann den Schreiner, Drucker, Maler, Dachdecker, Schornsteinfeger? shop=* mag gehen, trifft aber nicht genau. Doch, ziemlich genau sogar. Eine Schmiede ist laut Leo z.B. blacksmith's shop. Shop ist im englischen nicht gleich (Super-)Markt, wie wir es hier meist benutzen. besser wäre vielleicht trade=carpenter trade=printer etc. Gar nicht. trade=printer ist eventuell ein Druckerfachgeschäft und trade=carpenter verkauft Zimmerleute. ;-) craft=mason craft= Mag gehen, ist aber IMHO überflüssig. manufactory ist ähnlich. industry=car automobile industry=ship oder industry=wharft shipyard industry=brewerey oder industry=beer brewery Das jeweils andere (car, ship, beer) sind die Produkte, nicht der Industrietyp (industrie=schiff, industrie=bier) macht ja auch keinen Sinn. :) Und dann die Verwaltungsgebäude? Die Verwaltung des Versicherungsunternehmens, das Hauptquartier des Telekommunikationsunternehmens, die Filiale eines Softwareunternehmens? office=inssurance office=telecommunication function=headquarter klingt sinnvoll. Auch wenn ich das alles nicht taggen würde. Ändert sich zu schnell und der Informationsgewinn für den üblich Passanten ist eher gering, wenn er weiß, was in den nichts-sagenden Büros hinter der grauen Wand passiert. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relation Check - Neuigkeiten
Hi, der Check macht nun auch Boundaries und Routes. Kleine Verbesserungen und ein wenig Schminke gibt es auch. - via ist korrigiert - Multipolygone mit mehr als einem äußeren Ring werden nicht mehr angemeckert - Statistikausgabe - Link to Relation Analyzer Wiki Seite ist erweitert. http://wiki.openstreetmap.org/wiki/Relation_Check Bitte nochmal checken, falls Interesse... Falls jemand Ideen hat, wie man die Korrekturen einfach ansteuern kann, nur her damit! PS: Man glaubt es ja nicht, auf wieviele Arten man Mulipolynom schreiben kann... Siehe ganz unten im HTML. Ciao Gerhard gary68 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Jonas Krückel (John07) schrieb: Ja, nun letztlich zahlt halt der Bürger dann wieder an die Firma für die Daten im Navi oder sonstwo. :-) Irgendwann nicht mehr *G* ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Handwerk, Industrie, Wirtschaft und Verwaltung
Hallo, den Passanten mag es nicht interressieren. Aber vielleicht den Bürgermeister, Politiker oder Stadtkämmerer? Kurz vor der Wahl preisen die auch immer welche Unternehmen in die Stadt gelockt werden konnten und mit der Gewerbesteuer das Stadtsäckel füllen werden. Und all diese Unternehmen dann schön anschaulich auf einer Karte... Bis bald Harald black_bike Und dann die Verwaltungsgebäude? Die Verwaltung des Versicherungsunternehmens, das Hauptquartier des Telekommunikationsunternehmens, die Filiale eines Softwareunternehmens? office=inssurance office=telecommunication function=headquarter klingt sinnvoll. Auch wenn ich das alles nicht taggen würde. Ändert sich zu schnell und der Informationsgewinn für den üblich Passanten ist eher gering, wenn er weiß, was in den nichts-sagenden Büros hinter der grauen Wand passiert. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Handwerk, Industrie, Wirtschaft und Verwaltung
Am Tuesday 31 March 2009 21:17:33 schrieb Harald Schwarz: Hallo, Datenschutz mag ein Thema sein, wenn ungefragt Daten übernommen werden. Aber wo ist der Unterschied zwischen einem Kaufmann der Lebensmittel anbietet, einem Apotheker der Lebensmittel verkauft und einem Zimmermann der Dachstühle anbietet? Der Apotheker verkauft Arzneimittel ;-) Tippfehler! Die ersten beiden werden schon zahlreich in OSM erfasst. Warum sollte das für den dritten Fall problematischer sein? Bis bald Harald black_bike Am Tuesday 31 March 2009 11:59:14 schrieb Garry: Harald Schwarz schrieb: Hallo zusammen, Verkehr, Freizeit, Kultur, Bildung und Religion sind bei den Map Features schon gut abgedeckt. Bisher habe ich aber nur sehr wenig zu den Bereichen Handwerk, Industrie, Verwaltung gefunden. Auch bei den Proposed Features bin ich noch nicht auf diese Kategorien gestoßen. Das sollte meiner Meinung nach eigentlich ehr aus der OSM-Datenbank draussen bleiben und in einer separaten POI-Datenbank erfasst werden - schon alleine um das Thema Datenschutz aus OSM herauszuhalten. Könnte mir vorstellen dass es da Probleme geben kann wenn da plötzlich auch mehr oder weniger Privatadressen auf den Karten auftauchen mit denen der Besiter nicht einverstanden ist. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Jonas Krückel (John07) schrieb: Thomas Reincke schrieb: Imo sind das doch staatliche Institutionen und daher vom Bürger erstmal durch Steuergelder finanziert. Wenn sie jetzt den eigenen Bürger als Konkurrenz sehen, ist das etwas seltsam. Der ÖD ist im Umbruch! Es geht weg von der klassischen Kameralistik zur kaufmännischen Buchhaltung. Unter dem Stichwort NKF (neues kommunales Finanzwesen) tauchen Begriffe auf wie Bilanz und auch Produkte. Also auch manche Behörde produziert etwas und soll dabei möglichst Kosten deckend arbeiten (das funktioniert nicht überall, z.B. Sozialamt). Die so erzeugte Transparenz soll z.B. dazu führen, dass realistische Gebühren erhoben werden und keine Phantasiepreise. In dieses neue Bewusstsein passt es dann auch, wenn eine Behörde für ihre Produkte Einnahmen erzielen möchte, um die Kosten zu decken. Darunter fallen dann auch ALK und andere Geodaten. Der ÖD soll eben nicht mehr ein schwarzes Loch für Steuergelder sein. Es ist politischer Wille, dass er mehr wie ein Unternehmen gemanaged wird. Dazu gehört dann auch, dass er nichts mehr zu verschenken hat. -- Frank Jäger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nutzung der TMC Locationcode-Liste in OSM dur ch Bundesanstalt für Straßenwesen ERLAUBT!!!
In einem studentischen Projekt haben zwei Studierende unseres Studiengangs Vermessung und Geoinformatik (Jan Tunger und Paul Biskup) NMEA-Nachrichten zerlegt, die TMC-Nachrichten extrahiert und verarbeitet und einer Karte (zwar OpenLayers, aber leider kein OpenStreetMap) punktförmig überlagert. Es sind noch ein paar Punkte offen (z. B. Fahrtrichtungsabhängigkeit). ... momentan jedes Bisschen Information bezüglich dem Aufbau von TMC-Nachrichten und deren Einbettung in NMEA gebrauchen. Die beiden sind sicher sehr gut darin; sie werden auch sehr wahrscheinlich das Projekt noch fortsetzen, d. h. die Meldungen sollen als RSS-Feed verfügbar gemacht werden (nach Möglichkeit linienhaft auf der Basis von OSM). Einige Links hat damals Adrian Stabiszewski zusammengestellt [1], [2]. Und es gab einen Thread auf dieser Liste [3]. Den Stand bei Abschluss des Projekts finden man unter http://tmc.geogle.info/. Da die Daten seit Projektabschluss nicht mehr aktualisiert wurden, als Zeitraum eine große Zahl angeben, z. B. 96 ;-) Mit freundlichen Grüßen / Regards / Cordialement Franz-Josef -- http://www.applied-geoinformatics.org/ http://gis-news.de/ http://opengeocoding.org/ http://gis-management.de/ [1] http://www.capuzza.com/detail.php?ID=123764 [2] http://dev.inversepath.com/download/rds/srdsd [3] http://lists.openstreetmap.org/pipermail/talk-de/2008-December/032243.html Marcus Wolschon schrieb: Good news everyone! Wir dürfen: * Bestehender Punkte unserer frei verfügbaren Karte mit ihrem jeweiligen Locationcode taggen. * POIs (Tankstellen, Strassennamen,..) ais der TMC LocationCodeList zur Überprüfung der Vollständigkeit unserer Karte nutzen und ggf. Namen und Orte übernahmen. Vorgehen: # Sinnvollerweise sollten wir versuchen mit der vorliegenden LCL für Deutschland einen guten Arbeitsablauf für den späteren Import vom Rest von Europa zu etablieren. # Ich versuche jetzt erstmal mehr über die Arten, wie die LocationCodes in TMC-Nachrichten genutzt werden herauszufinden # dann werde ich wohl Hilfe für ein Tagging-Schema für TMC-Codes brauche. # auf http://apps.sourceforge.net/mediawiki/travelingsales/index.php?title=Plugin/TrafficMessageChannel#Convert_TMC_LoctionCodeList_to_OpenStreetMap steht schon ein Tool bereit, was eine TMC -LCL in OpenStreetMap umwandelt. Was wir brauchen ist aber eine Möglichkeit TMC-Nachrichten, welche sich auf die Punkte, Segmente, Wege, Gebiete, Richtungen und deren Verhältniss zueinander beziehen nutzbar auf unsere (wesentlich detailierteren) OSM-Daten abzubilden. Ich könnte momentan jedes Bisschen Information bezüglich dem Aufbau von TMC-Nachrichten und deren Einbettung in NMEA gebrauchen. Marcus == Sehr geehrter Herr Wolschon, vielen Dank für Ihre Anfrage zur Verwendung der Location Code List. Die Nutzung der LCL für Ihre Produkte und Anwendungen, wie in Frage 1,3 und 4 von Ihnen geschildert, ist zulässig, da Sie diese auch im Verwendungszweck angegeben haben. Von einer Veröffentlichung der LCL im originären Format und Umfang bitte ich jedoch abzusehen, ebenso von der Veröffentlichung der Dokumente, die Ihnen die BASt zusammen mit der LCL8.0 zugesandt hat. Interessenten der LCL können Sie auf die Bestellmöglichkeit bei der BASt hinweisen. Ihre 2. Frage zur Veröffentlichung einer ausführlichen Dokumentation des TMC-Exchange-Format, kann ich Ihnen nicht beantworten: Ich vermute, dass Sie mit TMC-Exchange-Format die vom TMC-Forum seinerzeit erstellten Dokumente und Standards für TMC meinen. Hier müssen Sie klären, inwieweit Urheberrechte bestehen. Eventuell wird man Ihnen bei TISA (www.tisa.org) weiterhelfen können, welche heute für alle Standardisierungsfragen in TMC zuständig ist. Die Veröffentlichung eines ganzen Standardpapieres, wie Sie es über DIN beziehen können, ist vermutlich auch nicht zulässig. Wenden Sie sich in dieser Frage eventuell auch an DIN e.V. bzw. Beuth-Verlag. Bei eigenen Dokumententationen zur LCL mit Zitaten und Auszügen bei entsprechenden Quellenangaben raten ich, im Zweifelsfall die entsprechenden Stellen anzuschreiben. Für Rückfragen stehe ich Ihnen gern zur Verfügung. Mit freundlichen Grüßen Im Auftrag Jessica Kleine Bundesanstalt für Straßenwesen Referat F4 Kooperative Verkehrs- und Fahrerassistenzsysteme Brüderstraße 53 51427 Bergisch Gladbach Telefon: 02204/43 644 Fax: 02204/43 676 E-Mail: kle...@bast.de -Ursprüngliche Nachricht- Von: Marcus Wolschon [mailto:mar...@wolschon.biz] Gesendet: Montag, 30. März 2009 14:41 An: BAST, LCL Betreff: Übernahme von Daten aus oder Referenzietung auf die Location Code List, Version 8.0 Guten Tag, mein Name ist Marcus Wolschon und ich entwickle das Navigationssystem Traveling Salesman für die Nutzung der freien Strassenkarte OpenStreetmap (http://openstreetmap.org) Ich würde gerne Anfragen ob einige der folgenden Nutzungen der deutschen Location Code List, Version 8.0 zugelassen werden: für mein
Re: [Talk-de] Handwerk, Industrie, Wirtschaft und Verwaltung
Harald Schwarz schrieb: Hallo, Datenschutz mag ein Thema sein, wenn ungefragt Daten übernommen werden. Aber wo ist der Unterschied zwischen einem Kaufmann der Lebensmittel anbietet, einem Apotheker der Lebensmittel verkauft und einem Zimmermann der Dachstühle anbietet? Die ersten beiden werden schon zahlreich in OSM erfasst. Warum sollte das für den dritten Fall problematischer sein? Der dritte Fall vermutlich noch nicht, aber der vierte Fall wenn die Teenies z.B. die Privatadressen Ihrer Stars (oder Lehrer) eingeben... Der nächste Schritt wäre dann die Türklingelschilder einzutragen... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Handwerk, Industrie, Wirtschaft und Verwaltung
Am 31. März 2009 20:45 schrieb Gerrit Lammert o...@00l.de: Hallo Harald. Harald Schwarz wrote: Darauf gestoßen bin ich als ich Handwerksbetriebe in meiner Umgebung erfassen wollte. Wie tagge ich dann den Schreiner, Drucker, Maler, Dachdecker, Schornsteinfeger? Gar nicht. trade=printer ist eventuell ein Druckerfachgeschäft und trade=carpenter verkauft Zimmerleute. ;-) craft=mason craft= Mag gehen, ist aber IMHO überflüssig. manufactory ist ähnlich. sehe ich nicht so. manufactory ist eine Manufaktur=industrieller Maßstab, craft ist der kleine Handwerker. industry=car automobile industry=ship oder industry=wharft shipyard industry=brewerey oder industry=beer brewery Das jeweils andere (car, ship, beer) sind die Produkte, nicht der Industrietyp (industrie=schiff, industrie=bier) macht ja auch keinen Sinn. :) ach so, Schiffsindustrie macht keinen Sinn? Wo liegt denn das der Unterschied zum Fahrzeugbau? Bei den Shops machen wir genau das: wir taggen den Shop nach den hauptsächlich angebotenen Produkten. Bei der Industrie würde ich eine nicht allzu kleinteilige Unterteilung vorschlagen (die man dann bei Bedarf noch mit Untertags verfeinern kann): Schwerindustrie (Montan), Bergbau Metallindustrie (Maschinenbau, Automobil, Schiffsbau, Luft- und Raumfahrt, Büromaschinen, Uhren, Feinmechanik, etc.) Holz Elektro (Elektrokleingeräte, Radio- und Fernseh, Textil (Bademode, Anzüge, Leder, Pelz, ...) Chemie (Kunststoff, Pharmazie, Mineralöl, Papier, ...) Bau (Gips, Türen, Fenster, Zement, Ziegel, etc.) Recycling und Abfallwirtschaft Konsumgüter (Lebensmittel, Tabak, Spielwaren, Druck, ...) diese Liste ist sicher nicht ansatzweise vollständig, am besten würde man sowas mal ins Wiki kopieren und dran weiterarbeiten, man sieht aber meiner Ansicht nach schon, dass sich eine Gruppierung anbietet: m.E. am besten 2 Hierarchiestufen (sonst wird zu kompliziert und kann man ja auch hinterher in der Auswertung weiter aufgliedern oder zusammenfassen). Wikipedia zitiert ISIC und nennt folgende: * 15 Lebensmittel und Getränken * 16 Tabakwaren * 17 Textilien * 18 Pelz * 19 Lederwaren * 20 Holz- und Korkartikeln * 21 Papierwaren * 22 Druckerzeugnisen * 23 Kohle-, Öl- und nuklearen Brennstoffen * 24 Chemieerzeugnissen * 25 Gummi und Plastik * 26 Nichtmetall-Produkten * 27 Metall-Produktion * 28 Metallwaren * 29 Maschinen und Ausrüstung * 30 Büromaschinen * 31 Elektrogeräten * 32 Radio- und Fernsehgeräten * 33 Uhren, medizinischen und optischen Geräten * 34 Fahrzeugen * 35 sonstigem Transportgerät * 36 Möbel * 37 Recycling Und dann die Verwaltungsgebäude? Die Verwaltung des Versicherungsunternehmens, das Hauptquartier des Telekommunikationsunternehmens, die Filiale eines Softwareunternehmens? office=inssurance insurance hm, wie genau wollen wir das denn machen? office=assets management? project controlling? Und wenn beides angeboten wird? Evtl. wäre es doch besser, einfach ein office mit Namen der Firma und Verweis auf den passenden Eintrag in einer Paralleldatenbank (in der dann Branche, Mitarbeiteranzahl, Kontaktinfos, Jahresumsatz, etc.) zu machen. office=telecommunication function=headquarter klingt sinnvoll. Auch wenn ich das alles nicht taggen würde. Ändert sich zu schnell und der Informationsgewinn für den üblich Passanten ist eher gering, wenn er weiß, was in den nichts-sagenden Büros hinter der grauen Wand passiert. wer mappt denn nur für Passanten? Der Standort der Hauptverwaltung von großen Firmen ändert sich zu schnell? Das glaube ich ehrlich gesagt auch nicht. Das ändert sich zwar hin- und wieder, dürfte aber deutlich langlebiger sein als die meisten der Bäcker, Schuhläden und Einbahnstraßen die wir sonst so taggen. Vor allem ist das dann mit dermaßen Getöse (z.B. in den Medien) verbunden, dass ein Update nicht schwer fallen sollte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Handwerk, Industrie, Wirtschaft und Verwaltung
Am 31. März 2009 21:51 schrieb Garry garr...@gmx.de: Der dritte Fall vermutlich noch nicht, aber der vierte Fall wenn die Teenies z.B. die Privatadressen Ihrer Stars (oder Lehrer) eingeben... Der nächste Schritt wäre dann die Türklingelschilder einzutragen... ja, und als closed source gibt's das auch schon lange. Wem es nicht passt, der kann die Löschung verlangen und/oder seinen Namen erst gar nicht an die Klingel schreiben. Schöne neue Computerwelt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellungnahme RVR und Stadt Dortmund
Am 31. März 2009 21:36 schrieb Frank Jäger fr...@fotodrachen.de: Jonas Krückel (John07) schrieb: Thomas Reincke schrieb: Imo sind das doch staatliche Institutionen und daher vom Bürger erstmal durch Steuergelder finanziert. Wenn sie jetzt den eigenen Bürger als Konkurrenz sehen, ist das etwas seltsam. Der ÖD ist im Umbruch! Es geht weg von der klassischen Kameralistik zur kaufmännischen Buchhaltung. Unter dem Stichwort NKF (neues kommunales Finanzwesen) tauchen Begriffe auf wie Bilanz und auch Produkte. Also auch manche Behörde produziert etwas und soll dabei möglichst Kosten deckend arbeiten (das funktioniert nicht überall, z.B. Sozialamt). Die so erzeugte Transparenz soll z.B. dazu führen, dass realistische Gebühren erhoben werden und keine Phantasiepreise. In dieses neue Bewusstsein passt es dann auch, wenn eine Behörde für ihre Produkte Einnahmen erzielen möchte, um die Kosten zu decken. Darunter fallen dann auch ALK und andere Geodaten. Der ÖD soll eben nicht mehr ein schwarzes Loch für Steuergelder sein. Es ist politischer Wille, dass er mehr wie ein Unternehmen gemanaged wird. Dazu gehört dann auch, dass er nichts mehr zu verschenken hat. -- Frank Jäger Schön und gut, aber wäre Steuerzahlen dann nicht wettbewerbsverzerrend? ;-) Die Bundeswehr ist z.B. einer der größten Posten im Haushalt, müssen deren Missionen jetzt Geld einbringen? Verstehst Du, was ich meine? NKF kann sicher für mehr Vergleichbarkeit und Transparenz sorgen, aber es ändert (sage ich mal vorbehaltlich der weiteren Prüfung, also ein bisschen uninformiert) nichts an der grundsätzlichen Tatsache, dass viele Leistungen des Staates Geld kosten, die sich nicht *direkt* durch Gebühren refinanzieren lassen. Das Sozialamt hattest Du ja schon selbst genannt. Daher halte ich auch nichts davon, die Geschlossenheit der öffentlichen Karten- und Geodaten zu verteidigen: Fakt ist, dass vorhandene Daten dadurch nicht annähernd so verbreitet und genutzt sind, wie sie sein könnten. Dieses Kartenmonopol ist z.T. ja auch gar nicht anzugreifen: wenn jemand ein Haus baut, muss er (gesetzlich vorgeschrieben) den genauen, vermaßten Lageplan (i.d.R. 1:1000 od. 1:500) und Baupläne (i.d.R. 1:100, Grundrisse, alle wesentlichen Schnitte und Ansichten) einreichen. Der Lageplan kann dann bequem übernommen werden ins System (digitales Liegenschaftskataster o.ä.). Solche Möglichkeiten haben wir bei OSM gar nicht: uns muss niemand genaue Pläne seines Hauses einreichen. Für die Prüfung dieser Pläne bezahlt man dann Genehmigungsgebühren, d.h. die Kosten dafür sind schon gedeckt. Wenn man nun anstatt eine Kasse zu betreiben, Prospekte zu drucken, sich über Preise Gedanken zu machen, Datenträger zu brennen, nicht mitgekaufte Daten rauszulöschen, alles zu prüfen, unzählige Mitarbeiter hierfür zu beschäftigen, etc. einfach einen freien Server (oder BIT-Torrent ;-) ?) aufsetzen würde, dann würden auch für die Verteilung der Daten viel weniger Kosten entstehen, als dies derzeit der Fall ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Darstellung von highway=road in Mapnik ändern?
Am 31. März 2009 12:11 schrieb Garry garr...@gmx.de: Mario Salvini schrieb: Die Idee von road war denjenigen die ständig einen GPS-Logger mit sich führen aber keine Zeit haben ihren Weg genauer zu spezifizieren dennoch die möglichkeit zu geben ihren Weg sichtbar in den OSM-Karten darstellen zu können. Da können auch Fähren, Autoreiszüge etc. dabei sein. Ich halte davon gar nichts. Entweder, man mappt dann halt ein paar Tracks weniger und dafür dort die Klassen auch anstatt nur road, oder man lässt es halt ganz. Aber pauschal mal so GPS-Tracks zu tracen macht m.E. kaum Sinn, vor allem nicht in bereits wohlgemappten Gefilden. Dummerweise hat das dazu geführt dass einige nur noch road eingetragen haben obwohl sie auf 1-2 Kategorien genau hätten eintragen können was es tatsächlich ist. ja, bedauerlich Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
