Re: [OSM-talk] sendmap in asus eeepc
Mine was communicating with a geko using serial connection (serial-USB converter) and the garmin protocol from gpsbabel, if that helps: http://wiki.openstreetmap.org/index.php/Asus_EEE I haven't tried it with sendmap -- isn't that a Windows program? The Asus runs Xandros by default. On Feb 11, 2008 8:23 AM, Lambertus [EMAIL PROTECTED] wrote: maning sambale wrote: Hi, Has anyone tried using sendmap to load garmin maps to GPS using asus eeepc [http://eeepc.asus.com/global/] Not tried it, but the Asus has an USB interface so if you GPS does as well (otherwise you 'could' try a USB to serial converter), then this should work. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Kosmos v1.10
Rodrigo Moya wrote: On Sun, 2008-02-10 at 22:00 +0100, Igor Brejc wrote: Hi everybody, I'm pleased to announce a new version of Kosmos, which has now become an open source project (BSD license). The new version comes with an enhanced rendering rule engine and new printing options. Also, some bugs were fixed in this release. More on the new version: http://igorbrejc.net/openstreetmap/kosmos/kosmos-110 I've just updated OSM Wiki pages with the new features. do you have any plan to fully support Kosmos running on Mono? For us without a windows machine, every announce you send makes us more jealous for not being able to use it :-) Of course, I'll be glad to help in testing and, when possible, sending patches Hi Rodrigo, Well there are plans, I already installed Mono in my machine, so I guess I made a first step :) . MoMA doesn't report too many errors, but I am a little bit skeptical about this - sounds too good to be true :) . I will try to port it to Mono as soon as possible, then I will contact you for any testing / patches. Thanks for contacting me! Best regards, Igor -- http://igorbrejc.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] relations in order not to fragment roads (was: correctly mapping avenues)
Hi, If we add a thing like segment relations as is proposed, we'll effectively end up with another level next to points, segments and relations (since things like route relations will again have these segment relations contained in them), which will likely increase complexity a lot in my eyes. Has anyone actually proposed such a thing? That would indeed be unnecessarily complex. As far as I understand it, the idea is simply to qualify a tag with start and end node. I.e. you have a way that goes from node A, B, C to Z, but from B to D and from M to P it is a pedestrian road. So, old scheme: split way into 5 parts (3 non-pedestrian, 2 pedestrian) and tag accordingly. scheme with superway relation: split way into 5 parts and create one relation to contain them all; add all common tags to relation; add pedestrian tag to 2 ways. scheme with qualified tag relations: do not split way. create two relations that each contain the way, plus the start and end node (B/D for relation 1 and M/P for relation 2), plus the special tag (pedestrian). Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] relations in order not to fragment roads (was: correctly mapping avenues)
On Monday 11 February 2008, Karl Newman wrote: That seems like a reasonable approach--see my reply to Bernd's email in another forked thread. The way should be long, but not unreasonably so, and if the name or highway type changes, that seems like a logical place to split it. I thought with the addition of relations we would go towards moving all information up from ways to segments. So instead of putting for example the street name in the way, put it in a relation (and that would immediately solve things like dual carriage ways or cul-de-sacs with the same street name, which need different ways anyway). If a road has a reference number, put it also in a relation together with all other roads with that reference, etc. So, in my eyes it would be something like splitting ways up at all junctions (to my knowledge that also simplifies things for route planners), or on metadata changes like speed, and move info up if more than one way belongs to the same property. If we add a thing like segment relations as is proposed, we'll effectively end up with another level next to points, segments and relations (since things like route relations will again have these segment relations contained in them), which will likely increase complexity a lot in my eyes. Greetings Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] relations in order not to fragment roads (was: correctly mapping avenues)
On Feb 11, 2008 10:36 AM, Martin Trautmann [EMAIL PROTECTED] wrote: Karl Newman wrote: To me, the nodes and ways should follow the physical world as much as possible--the road didn't change just because the speed limit changed, so why chop it up? I changed the subject now - and I agree, roads should be kept as roads. The more details you add, the more fragments you would get. When a proprety of the road at its full length does change, you have to adjust every single piece. There are occasions where a certain split has to be done. Take e.g. a national route which passes several cities. It could be called e.g. B3 (which would be the German Bundesstraße 3) which is several hundred kilometers long and passes through dozens of towns and villages. Whenever the town boarder is reached, the B3 may follow a line of residential roads. I feel that a split is required here - the full length of the road can be found by the ref tag. That seems like a reasonable approach--see my reply to Bernd's email in another forked thread. The way should be long, but not unreasonably so, and if the name or highway type changes, that seems like a logical place to split it. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] correctly mapping avenues
On Feb 11, 2008 8:58 AM, Gervase Markham [EMAIL PROTECTED] wrote: Karl Newman wrote: Big +1 on this proposal. That's exactly what I've been thinking about lately. It's stupid to chop up nice long ways just because the speed limit changes or the way happens to cross a bridge. Isn't this exactly why relations were invented? To unite a set of ways with a common attribute? Or have I misunderstood? Gerv I think it depends on the perspective you take. To me, the nodes and ways should follow the physical world as much as possible--the road didn't change just because the speed limit changed, so why chop it up? Either way we go, it's going to require good editor support for this, but to me, it's easier to manage one long way than to hunt down and select each constituent way if I want to change some aggregate property (I've done some editing of the TIGER data). I think it also does more to encourage an iterative, incremental approach to data refinement--first get the physical tracks down, then add speed limits, lanes, surface information, etc. I know, it would be great if all that stuff was done at once, but putting an emphasis on getting the physical ways in place first does more to expand OSM coverage and make visual progress to the renderers, and makes OSM more useful to more people, sooner. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Kosmos v1.10
On Sun, 2008-02-10 at 22:00 +0100, Igor Brejc wrote: Hi everybody, I'm pleased to announce a new version of Kosmos, which has now become an open source project (BSD license). The new version comes with an enhanced rendering rule engine and new printing options. Also, some bugs were fixed in this release. More on the new version: http://igorbrejc.net/openstreetmap/kosmos/kosmos-110 I've just updated OSM Wiki pages with the new features. do you have any plan to fully support Kosmos running on Mono? For us without a windows machine, every announce you send makes us more jealous for not being able to use it :-) Of course, I'll be glad to help in testing and, when possible, sending patches -- Rodrigo Moya [EMAIL PROTECTED] ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] some problem with video.py
Edoardo Marascalchi wrote: [EMAIL PROTECTED] video rendering]$ AttributeError: 'cairo.ImageSurface' object has no attribute 'get_data_as_rgba' bash: AttributeError:: command not found Any advice? This might be a shot in the dark... http://www.nabble.com/-cairo--ANN:-pycairo-release-1.2.6-now-available-p7591133.html * ImageSurface.get_data() new method added ImageSurface.*get_data_as_rgba*() method removed Try downgrade to a pycairo 1.2.6? / Grant ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] correctly mapping avenues
On Feb 11, 2008 7:20 AM, Bernd Raichle [EMAIL PROTECTED] wrote: Hi, on Sunday, 10 February 2008 08:34:31 -0800, Karl Newman [EMAIL PROTECTED] writes: On Feb 10, 2008 4:21 AM, Frederik Ramm [EMAIL PROTECTED] wrote: Since trees lining a way/street are such a common occurence, why not have a simple additional tag to the main road. lined_by_trees=yes/no/left/right I'm a bit unhappy about needlessly inflating the importance of the direction of ways. Long-term, I would actually like to get rid of the direction and express everything in relations. This means, that you find it necessary to have something like a direction or a side, both of this features related to a way? But you don't want to express a direction or a side by the _implicit order_ of the way nodes. The reasons for this are (a) the direction is too easily changed, sometimes by mistake ... because none of the current OSM editors show direction- or side-related tags explicitly. (b) there might be multiple conflicting things that rely on the direction, e.g. a road that is oneway from A to B but has a slope from B to A Anything with left/right in it also relies on direction. I'd prefer east/west/north/south, or using an explicit relation that says trees on the right between nodes A and B along road C. I am against east/west/north/south because there are a lot of ways/areas/things which do not go straight ahead. Okay, this thread is at risk of spinning wildly off-topic, but I've been thinking about this situation recently. It seems to clamor for the use of specialized relations that are direction-aware. That way, if a way is a member of a relation and has directional properties (left/right), then the editors could look for those relations when the way is reversed and either fix them automatically or at the minimum raise a warning dialog. I also had some other ideas about enforcing referential integrity for another type of specialized relation (if one or more node relation members is required to be part of a way relation member, then enforce that rule). That rule could actually be enforced by the API. These specialized relations would just give some structure to the wide-open relation type, without implying anything about the nature of the relation. It could possibly be accomplished through special tags on the existing relation structure. Do you have any propositions how this will look like or how this should be done? A few days ago I have started a new proposal for a Segmented Tag, which relates a set of tags to a directed or undirected part of a way (I have called this part segment inspired by GDF's Segmented Attributes). I have not found the time yet to finalize the proposal adding some examples, nonetheless it can already be found in the OSM Wiki (Relations/Proposed/Segmented Tags). Best wishes, -bernd Big +1 on this proposal. That's exactly what I've been thinking about lately. It's stupid to chop up nice long ways just because the speed limit changes or the way happens to cross a bridge. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] correctly mapping avenues
Hi, on Sunday, 10 February 2008 08:34:31 -0800, Karl Newman [EMAIL PROTECTED] writes: On Feb 10, 2008 4:21 AM, Frederik Ramm [EMAIL PROTECTED] wrote: Since trees lining a way/street are such a common occurence, why not have a simple additional tag to the main road. lined_by_trees=yes/no/left/right I'm a bit unhappy about needlessly inflating the importance of the direction of ways. Long-term, I would actually like to get rid of the direction and express everything in relations. This means, that you find it necessary to have something like a direction or a side, both of this features related to a way? But you don't want to express a direction or a side by the _implicit order_ of the way nodes. The reasons for this are (a) the direction is too easily changed, sometimes by mistake ... because none of the current OSM editors show direction- or side-related tags explicitly. (b) there might be multiple conflicting things that rely on the direction, e.g. a road that is oneway from A to B but has a slope from B to A Anything with left/right in it also relies on direction. I'd prefer east/west/north/south, or using an explicit relation that says trees on the right between nodes A and B along road C. I am against east/west/north/south because there are a lot of ways/areas/things which do not go straight ahead. Okay, this thread is at risk of spinning wildly off-topic, but I've been thinking about this situation recently. It seems to clamor for the use of specialized relations that are direction-aware. That way, if a way is a member of a relation and has directional properties (left/right), then the editors could look for those relations when the way is reversed and either fix them automatically or at the minimum raise a warning dialog. I also had some other ideas about enforcing referential integrity for another type of specialized relation (if one or more node relation members is required to be part of a way relation member, then enforce that rule). That rule could actually be enforced by the API. These specialized relations would just give some structure to the wide-open relation type, without implying anything about the nature of the relation. It could possibly be accomplished through special tags on the existing relation structure. Do you have any propositions how this will look like or how this should be done? A few days ago I have started a new proposal for a Segmented Tag, which relates a set of tags to a directed or undirected part of a way (I have called this part segment inspired by GDF's Segmented Attributes). I have not found the time yet to finalize the proposal adding some examples, nonetheless it can already be found in the OSM Wiki (Relations/Proposed/Segmented Tags). Best wishes, -bernd ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Shapefile download
Hi, I'm planning to offer the download of current OSM shapefiles for various European countries. I've done a test run and there are some files to play with at: http://download.geofabrik.de/osm/europe/ Great! How much does it cost? Well I was not planning to charge for it but if you want to pay me something that's fine ;-) I mean: can you manage to do other countries (Italy is missing). Just added Italy, but it will take an hour or so to show up. Otherwise, how complicate is to replicate this work on our own? A wiki page or a README will be required soon, IMO! The basic procedure is this: * obtain latest planet (or an excerpt large enough, e.g. europe.osm) * obtain a polygon file that describes the section you want to cut out, possibly from maproom.psu.edu * use osmosis to cut out the are from the planet file * use a suitable shapefile generation tool, e.g. osmexport, to generate shapefiles from that. The shapefile generation will require some configuration (how many shapefiles? what to put in them? which tags to convert?) and I have chosen some simple general settings for my download stuff, thinking that if anyone needs something sophisitcated they'll do their own anyway. In addition to the above procedure, if you want to do the same thing on a daily basis and possibly for a big number of areas, you will want to do the following: * edit your polygon files (use the poly2osm/osm2poly scripts that I have recently put into SVN, then you can modify the polygon using JOSM) - files from maproom.psu.edu are often more detailed than need be * download daily diffs instead of full planets, and apply them to your local copy using osmosis * automate the whole process The only script I'm using that is not yet published is a C impleme- ntation of a subset of osmexport's capabilities which is far less flexible but a bit faster and less memory consuming, but the existing osm2shp.cpp would probably have done the job as well. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Shapefile download
I'm planning to offer the download of current OSM shapefiles for various European countries. I've done a test run and there are some files to play with at: http://download.geofabrik.de/osm/europe/ Great! How much does it cost? I mean: can you manage to do other countries (Italy is missing). Otherwise, how complicate is to replicate this work on our own? A wiki page or a README will be required soon, IMO! Thanks. -- Niccolo Rigacci Firenze - Italy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Source of Nokia footpath maps?
On 11/02/2008, Andy Allan [EMAIL PROTECTED] wrote: Is there anything to say that it'll have footpaths on it? It would be fairly easy to take teleatlas etc, ignore the oneway tags and call it pedestrian-optimised, and few people will notice until they are out of town. :-) Navteq you must mean. ;) National mapping agencies and cities definately have footpath information available if you are willing to pay for it. -- Lauri Hahne ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] correctly mapping avenues
Karl Newman wrote: Big +1 on this proposal. That's exactly what I've been thinking about lately. It's stupid to chop up nice long ways just because the speed limit changes or the way happens to cross a bridge. Isn't this exactly why relations were invented? To unite a set of ways with a common attribute? Or have I misunderstood? Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] correctly mapping avenues
On Mon, Feb 11, 2008 at 04:20:02PM +0100, Bernd Raichle wrote: (a) the direction is too easily changed, sometimes by mistake ... because none of the current OSM editors show direction- or side-related tags explicitly. Merkaartor does for the direction related tags it understands. I need to add support for more such tags though. I am against east/west/north/south because there are a lot of ways/areas/things which do not go straight ahead. Yes. A few days ago I have started a new proposal for a Segmented Tag, which relates a set of tags to a directed or undirected part of a way (I have called this part segment inspired by GDF's Segmented Attributes). I have not found the time yet to finalize the proposal adding some examples, nonetheless it can already be found in the OSM Wiki (Relations/Proposed/Segmented Tags). I am not really sure about this. Just splitting the ways seems less complex? An obvious problem with your proposal seems that it does not specify what happens with conflicting segmentations (ie, way A-B-C-D-E and segmented relation X says from A till D is 90kmp maxspeed and segmented relation Y says from B till E is 70kmp maxspeed. cu bart ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Large Rivers in general, mapnik rendering in Particular
David Groom wrote: I'll edit the wiki. Could you put some visual examples, please? Artem, what i had in mind is now shown on http://wiki.openstreetmap.org/index.php/Relations/Proposed/Rivers David G I'm a bit late in entering this discussion, but at the first glance I see at least one problem with this proposal: representing tributaries (http://en.wikipedia.org/wiki/Strahler_Stream_Order), which must be treated separately, since their usually have their own names. Either you would have to define an OSM way splitting the main river and the tributary (which in a sense defeats the idea of this proposal) or you would let the renderer assume that it can draw such a segment by itself (which can sometimes be problematic, I suppose). I'm not against letting renderers do their jobs, but I think we should not presume that all devices will have CPUs powerful enough to provide interactive maps by processing complex geometry algorithms. Drawing something like this, for example: http://en.wikipedia.org/wiki/Image:Mouths_of_amazon_geocover_1990.png :) Igor -- http://igorbrejc.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Source of Nokia footpath maps?
Someone sent me this link with Nokia launching some old guff about handheld navigation on foot. http://newsvote.bbc.co.uk/1/hi/technology/7230686.stm Which lead me to wonder where the footpath information might be coming from, considering all we usually see from Navteq/Teleatlas is roads and branches of McDonalds. As far as I know the only decent footpath mapping in the UK (apart from the bits done in OSM ;-) is from Ordnance Survey. What about other countries? Anyone have further info, or perhaps a less vague article? Ben -- [EMAIL PROTECTED] | http://crouchingbadger.com 51.717817,-1.225855 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Some interesting numbers from planet.osm
On Sun, Feb 10, 2008 at 06:54:44PM -0500, Adam Schreiber wrote: I hope that you do know that not every highway 0 nodes in the JOSM relations window really has 0 nodes. It just means that the way was not downloaded from the server because it lies completely outside of the downloaded area. So if people are removing all highway 0 nodes they encounter (if that is possible?), then they are breaking the relations. Could JOSM be modified to get all members of a downloaded relation or mark the real 0 node ways somehow? In fact, JOSM doesn't name incomplete ways as 0 nodes since more than a month[1]. Nowadays incomplete ways are just shown as incomplete. [1] http://josm.openstreetmap.de/changeset/505 Gabriel. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] administrative boundaries that run along roads - in the Mapnik layer
Hmm. Since the layer tag is supposed to be for defining the relative vertical displacement of physical features, I think I will rustle up a patch to osm2pgsql to strip off layer tags for non-physical features like admin boundaries :-) If we (or any renderer) want the admin boundaries showing above roads, it should be controlled through the rendering process rather than using layer=. For example, I would move the administrative rendering rule in osm.xml to a separate style from minor-roads, and then put that style in a separate layer. Cheers, Andy On Feb 10, 2008 7:41 PM, Steve Chilton [EMAIL PROTECTED] wrote: Where I have been mapping admin boundaries I put them all in as layer=1 - this brings them above most things in the mapnik rendering. See: http://www.openstreetmap.org/?lat=51.60655lon=-0.05558zoom=15layers=B0FT Cheers STEVE -Original Message- From: [EMAIL PROTECTED] on behalf of Adrian Frith Sent: Sun 2/10/2008 7:06 PM To: [EMAIL PROTECTED] Cc: Subject: [OSM-talk] administrative boundaries that run along roads - in the Mapnik layer Hi All, In Cape Town we've been mapping the suburb boundaries (which are official) as boundary=administrative admin_level=10. These boundaries run often down the middle of roads, railways or rivers. They show up very nicely on the Osmarender/[EMAIL PROTECTED] layer as dashed red lines - see for example http://www.openstreetmap.org/?lat=-33.95lon=18.45zoom=12layers=0BFT On the Mapnik layer, however, they show up only where they do *not* run along roads or railways - it seems that the other features are rendered on top of the boundaries. Should we not be rendering administrative boundaries above real features? My understanding is that this would require a change to the z_order code in osm2pgsql. Is that correct? Regards, Adrian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] User umehlig and some really nasty edits
On Feb 11, 2008 9:44 AM, Tom Hughes [EMAIL PROTECTED] wrote: I don't know if there is a page anywhere that documents the format of JOSM change files? http://wiki.openstreetmap.org/index.php/JOSM_file_format On the more general idea of change file formats: http://wiki.openstreetmap.org/index.php/Change_File_Formats Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] sendmap in asus eeepc
maning sambale wrote: Hi, Has anyone tried using sendmap to load garmin maps to GPS using asus eeepc [http://eeepc.asus.com/global/] Not tried it, but the Asus has an USB interface so if you GPS does as well (otherwise you 'could' try a USB to serial converter), then this should work. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] relations in order not to
As far as I understand it, the idea is simply to qualify a tag with start and end node. I.e. you have a way that goes from node A, B, C to Z, but from B to D and from M to P it is a pedestrian road. So, old scheme: split way into 5 parts (3 non-pedestrian, 2 pedestrian) and tag accordingly. scheme with superway relation: split way into 5 parts and create one relation to contain them all; add all common tags to relation; add pedestrian tag to 2 ways. scheme with qualified tag relations: do not split way. create two relations that each contain the way, plus the start and end node (B/D for relation 1 and M/P for relation 2), plus the special tag (pedestrian). Am I the only one reading this discussion thinking that editing on OSM is going to get so complicated that we'll have very few new contributors, and certainly not many non-techies? I agree that segmenting roads is not ideal, but I'm just trying to think about the way that relation data will be presented to users for editing with either of these two models. Perhaps that's cart before horse, but it worries me. I started playing with OSM just after segments had been done away with, and sometimes I wonder why that happened, not having ever used them. It seems to me that the current proposals regarding ways/relations are somewhat similar to segments/ways. The qualified tag approach seems like ways become what was segments, except they cover more than one node, and the relations become what was ways... or am I misunderstanding somewhat? I feel that the term relation for something that is basically a meta-data-carrying way will be confusing for newcomers. The use of relation for saying that two ways are related makes more sense. Sorry for the rambling stream-of-conciousness, anyway! Dave __ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] some problem with video.py
Grant Slater ha scritto: Edoardo Marascalchi wrote: [EMAIL PROTECTED] video rendering]$ AttributeError: 'cairo.ImageSurface' object has no attribute 'get_data_as_rgba' bash: AttributeError:: command not found Any advice? This might be a shot in the dark... http://www.nabble.com/-cairo--ANN:-pycairo-release-1.2.6-now-available-p7591133.html * ImageSurface.get_data() new method added ImageSurface.*get_data_as_rgba*() method removed Try downgrade to a pycairo 1.2.6? but this was committed on 2006.. how could the script work if the method was deleted 1 year ago?? Mikel, have you patched the script? Edo -- Edoardo Marascalchi ICT Consultant website: http://www.edoardomarascalchi.it skype: My status skype:asca_edom?call ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] unpaved residential
Robin Paulson schrieb: On 11/02/2008, Alex S. [EMAIL PROTECTED] wrote: Lukasz Stelmach wrote: 1. why there is (i'll answer it in a moment) unsurfaced highway while in practice every highway can have surface=unpaved? Highway=unsurfaced is old. Surface=unpaved is much more recent, and should be used by preference, IMO. totally. +1 from me. I think we should make this a Deprecated feature as long as nobody objects. Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] User umehlig and some really nasty edits
On Mon, Feb 11, 2008 at 08:44:21AM +, Tom Hughes wrote: I don't know if there is a page anywhere that documents the format of JOSM change files? Nothing sophisticated. Everything with a negative id gets created, everything with an action=modify attribute is uploaded, and everything with an action=delete attribute is deleted. For example the following will cause one PUT to /api/0.5/node/create, one PUT to /api/0.5/way/1234 and one DELETE to /api/0.5/way/5678. node id=-1 lat=0 lon=0/ way id=1234 action=modify nd ref=100/ nd ref=200/ /way way id=5678 action=delete nd ref=600/ nd ref=700/ /way Gabriel. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Mapnik: right-to-left labels are printed backward
Hebrew and Arabic labels have to be printed in right-to-left order, but are reversed by Mapnik. See the differences between the way they are printed in the Mapnik (incorrect) and Osmarenderer (correct) layers. Hebrew: http://www.openstreetmap.org/?lat=31.6786lon=34.5695zoom=14 Arabic: http://www.openstreetmap.org/?lat=33.8935lon=35.4925zoom=12 Moshe ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] RFC: Highway administrative and physical descriptions
Hi, Please read and comment on the proposal at http://wiki.openstreetmap.org/index.php/Proposed_features/Highway_administrative_and_physical_descriptions The highway:physical enumeration cries out for one of those decision-charts, don't know how they're called in English, the ones where you always have a yes/no question and are routed to the next question depending on your answer, and finally arrive at your desired result. The wiki page has a kind of poetic quality to me, with its talk if super_twos and suicide lanes, and how there's a street type for every phase of a man's life (from being a minor via the primitive stages you become significant, then you might link to become a super_two... oh well I think I should rather go to bed now. Not the kind of comment you were asking for, probably. Sounds like it's never going to work, to be honest. But do try. (BTW, AFAIK, over here in Germany E-roads are exclusively motorways, and they all have the E-number in addition to a national number.) Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Japanese place names not rendered in Mapnik
Sorry if this has been mentioned before, but Japanese isn't being rendered in Mapnik properly - I am just seeing a rectangle for each character. eg http://www.openstreetmap.org/?lat=35.711lon=139.869zoom=11layers=B0FT Anyone know what to do about this? Thanks, Dave __ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] [tagging] RFC: Highway administrative and physical descriptions
Please read and comment on the proposal at http://wiki.openstreetmap.org/index.php/Proposed_features/Highway_administrative_and_physical_descriptions Thank you. -Alex Mauer hawke signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] User umehlig and some really nasty edits
In message [EMAIL PROTECTED] Martijn van Oosterhout [EMAIL PROTECTED] wrote: On Feb 10, 2008 10:51 PM, Lukasz Stelmach [EMAIL PROTECTED] wrote: All right I confess. I have done something like that to the node 300 a while ago. But while you are considering some solutions to this problem allow me to explain myself. I tried to find out how to create and upload osm file by hand (i like vi that myuch ;) But there is no single word written here http://wiki.openstreetmap.org/index.php/OSM_Protocol_Version_0.5 on how to obtain or create new id. It is described how to create an object but not how to choose an id for it. As far as I can tell it says it right here: http://wiki.openstreetmap.org/index.php/OSM_Protocol_Version_0.5#Basic_Methods_for_Object_Access_and_Manipulation To create you use PUT and it returns an ID. Indeed. I think the problem is that he is reading a page that documents the HTTP API and expecting it to tell him the format of a JOSM change file. I don't know if there is a page anywhere that documents the format of JOSM change files? Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Japanese place names not rendered in Mapnik
In message [EMAIL PROTECTED] David Ebling [EMAIL PROTECTED] wrote: Sorry if this has been mentioned before, but Japanese isn't being rendered in Mapnik properly - I am just seeing a rectangle for each character. eg http://www.openstreetmap.org/?lat=35.711lon=139.869zoom=11layers=B0FT Anyone know what to do about this? Yes - Talk to Artem about adding support to mapnik for fallback fonts, or find us a font we can use instead of DejaVu which is known to support every possible glyph for every character set. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] sendmap in asus eeepc
OJ W wrote: Mine was communicating with a geko using serial connection (serial-USB converter) and the garmin protocol from gpsbabel, if that helps: http://wiki.openstreetmap.org/index.php/Asus_EEE I haven't tried it with sendmap -- isn't that a Windows program? The Asus runs Xandros by default. Sendmap comes in Linux and Windows flavors :) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] RFC: Highway administrative and physical descriptions
Frederik Ramm wrote: .. one of those decision-charts, don't know how they're called in English, the ones where you always have a yes/no question and are routed to the next question depending on your answer, and finally arrive at your desired result. The term you're looking for is either flowchart or decision tree. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] EUR 15K grant for software development
Hi all, Back in November '07 I raised the issue of most pressing software development issues [1]. The objective was to give body to a proposal we were preparing for NLNet [2], which would include a grant for software development. The resulting discussion on talk / dev and discussion within the Dutch chapter led to a proposal submitted on Dec. 1st. The proposal is in Dutch and encompasses much more than the software development. It is available here [3]. Last month NLNet granted our request for funding -- at least, the software development part. So now we have EUR15k to spend on various development projects! Great, huh? This is how we think we should proceed: 1. I'll set a page up on the Wiki up to enable us to finetune the projects we're going to be supporting (asap). Starting point will be the central issues outlined in the proposal: a. Monitoring and Rollback b. Mobile Editor c. 'Map annotation for the rest of us' 2. We'll have a review period to finalize the project definitions. This can't last too long, NLNet wants to see progress. Two weeks max. 3. After the review, I submit the definitive project plans to NLNet for approval. 4. On approval, anyone (individual or group) would be able bid on the projects. After that, we agree on who's doing what and we can start implementation. NLNet will require close monitoring, a transparent process, definition of milestones and progress reports throughout the year. This will be an excellent opportunity to catalyse some of the OSM development projects, don't you agree? Let's hear your thoughts on this, I'll let you know when the wiki is done. On behalf of the Dutch chapter, Take care, Martijn [1] http://lists.openstreetmap.org/pipermail/talk/2007-November/020409.html [2] http://nlnet.nl/ [3] http://www.xs4all.nl/~exel0/osm/OSM%20subsidieaanvraag%202008.rtf -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk-nl] Tele Atlas introduceert gps-kaarten voorvoetgangers
Dat kunnen wij helemaal niet beter. Ja misschien de software, maar onze kaarten zijn evenmin geschikt voor voetgangers als die van teleatlas. Hier moet nog ontzettend veel mapwerk verricht worden. We weten niet hoe goed de data van TA feitelijk is op dat gebied. Mijn opmerking was dan ook meer bedoeld als aansporing! Delft staat er al wel best aardig in: http://www.tile.openstreetmap.nl/?zoom=15lat=52.01161lon=4.35949layers=B00F Maar ja tot hoever wil je gaan met die steegjes, lijkt me dat steegjes naar iemands achtertuin niet nuttig zijn ook al zou je die wel op een kaart kunnen zien. gr Joris it wasn't me Meijerink ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] Leuk voor een toekomstige 'ludieke' PR-actie?
Een samenwerking met deze lieden: http://www.gpsdrawing.com/ Misschien wel geinig :) -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsroutenetwerk-punten automatiseren?
Wat zijn de voordelen hiervan? Ik kan me voorstellen dat het snellere parsers zijn; nu gaat het niet heel snel maar ik vind een halve minuut nog best acceptabel. Ik kan me niet voorstellen dat ze veel minder geheugen gebruiken als ze dezelfde datastructuur maken (DOM). Dus ik zie niet in dat ze het geheugenprobleem op kunnen lossen. Verder lijkt het mij geen probleem als een programma voor een eenmalige import nogal lang nodig heeft om te draaien. Zelfs als ik het een uur zou moeten laten draaien, zou ik daar geen problemen mee hebben. Het is toch eenmalig. Als je echter te weinig geheugen beschikbaar hebt, gaat dit niet lukken. Dus daar zul je iets aan moeten. Persoonlijk gaat mijn voorkeur nog altijd uit naar Java, omdat ik daarin veel sneller een programma kan schrijven. Maar voor de c kenners is een iets snellere implementatie in c natuurlijk wel een goede keuze. Steven Stefan de Konink schreef: Heb je wat je wilt doen al eens geprobeerd met expat of msxml? Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Tele Atlas introduceert gps-kaarten voorvoetgangers
Dat is inderdaad waar ik hier in de buurt nu mee bezig ben. Alle doorsteekjes en pleintjes/plantsoentjes binnen de flatblokken die publiek toegangkelijk zijn op de kaart zetten. Het was namelijk heel mooi weer afgelopen weekeinde. Bij mij ligt de grens niet of het dood loopt, maar of het toegankelijk is. (Ik moet er toch eerst inlopen met m'n GPS, voordat ik weet dat het dood loopt.) Alles met een poort ervoor of een verboden toegang bordje zet ik niet op de kaart, hoewel het wel zou kunnen met access=private. Deze paadjes lopen hier namelijk meestal kaarsrecht en je kunt aan beide uiteinden komen. Cartinus On Mon, 11 Feb 2008 13:31:13 +0100 Martijn van Exel [EMAIL PROTECTED] wrote: Interessant voor zover ze publiek toegankelijk zijn en relaties in het stratennetwerk representeren. Dus een doodlopend steegje waar geen adressen aan liggen wellicht niet, een steegje tussen twee huizen dat twee straten verbindt dan weer wel. Op 11 feb 2008, om 12:58 heeft Joris Meijerink het volgende geschreven: Dat kunnen wij helemaal niet beter. Ja misschien de software, maar onze kaarten zijn evenmin geschikt voor voetgangers als die van teleatlas. Hier moet nog ontzettend veel mapwerk verricht worden. We weten niet hoe goed de data van TA feitelijk is op dat gebied. Mijn opmerking was dan ook meer bedoeld als aansporing! Delft staat er al wel best aardig in: http://www.tile.openstreetmap.nl/?zoom=15lat=52.01161lon=4.35949layers=B00F Maar ja tot hoever wil je gaan met die steegjes, lijkt me dat steegjes naar iemands achtertuin niet nuttig zijn ook al zou je die wel op een kaart kunnen zien. gr Joris it wasn't me Meijerink ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] EUR 15K grant for software development
Hi all, Back in November '07 I raised the issue of most pressing software development issues [1]. The objective was to give body to a proposal we were preparing for NLNet [2], which would include a grant for software development. The resulting discussion on talk / dev and discussion within the Dutch chapter led to a proposal submitted on Dec. 1st. The proposal is in Dutch and encompasses much more than the software development. It is available here [3]. Last month NLNet granted our request for funding -- at least, the software development part. So now we have EUR15k to spend on various development projects! Great, huh? This is how we think we should proceed: 1. I'll set a page up on the Wiki up to enable us to finetune the projects we're going to be supporting (asap). Starting point will be the central issues outlined in the proposal: a. Monitoring and Rollback b. Mobile Editor c. 'Map annotation for the rest of us' 2. We'll have a review period to finalize the project definitions. This can't last too long, NLNet wants to see progress. Two weeks max. 3. After the review, I submit the definitive project plans to NLNet for approval. 4. On approval, anyone (individual or group) would be able bid on the projects. After that, we agree on who's doing what and we can start implementation. NLNet will require close monitoring, a transparent process, definition of milestones and progress reports throughout the year. This will be an excellent opportunity to catalyse some of the OSM development projects, don't you agree? Let's hear your thoughts on this, I'll let you know when the wiki is done. On behalf of the Dutch chapter, Take care, Martijn [1] http://lists.openstreetmap.org/pipermail/talk/2007-November/020409.html [2] http://nlnet.nl/ [3] http://www.xs4all.nl/~exel0/osm/OSM%20subsidieaanvraag%202008.rtf -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Scriptje om tiles te downloaden en aaneen te plakken
Dit is wat je nodig hebt: http://tah.openstreetmap.org/MapOf/ Groeten Johan Maarten Deen wrote: Voor de mapping party in Mechelen had ik wat tiles gedownload en die met Imagemagick aan elkaar geplakt. Dat is natuurlijk perfect te automatiseren. Is daar al een scriptje voor of zal ik die even maken? Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] Enschede Party
Ha allen, Komend weekend zijn een aantal van ons in Enschede voor een technische meeting. Het idee was om dit te combineren met wat mapping effort. Wie heeft zin om dit verder te organiseren? Het is vooral een kwestie van locatie, mensen warm maken en eventueel van tevoren wat geschikte gebieden uitzoeken (er is al een discussie op de Wiki[1] en een TODO- list[2]). Helemaal mooi zou zijn als er wat lokale en regionale pers gemobiliseerd zou kunnen worden. [1] http://wiki.openstreetmap.org/index.php/Netherlands_Mapping_Parties_2008#Enschede_en_omstreken [2] http://wiki.openstreetmap.org/index.php/Enschede#Todo-list_Enschede -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Tele Atlas introduceert gps-kaarten voorvoetgangers
Het zou zomaar kunnen dat ze een topo-kaart met hun huidige kaarten hebben gecombineerd. Daarop staat wel al veel steegjes, maar ook veel andere dingen, zoals onverharde bospaadjes, steegjes en bruggetjes. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Artikel in Leeuwarder Courant naar aanleiding persbericht Friese kaart
Deze kop snap ik trouwens niet: http://www.dutchcowboys.nl/local/12761/fromfeed/1 Heh, ik ook niet... Dat krijg je dan als je twee dingen tegelijk doet... Verwarring alom. Jo ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] EUR 15K grant for software development
Gefeliciteerd. Zowaar een fantastisch resultaat. Ik denk dat we wel even na moeten denken op basis waarvan eventuele software auteurs betaald moeten worden. Tegen de marktconforme tarieven van softwarehouses, is de pot natuurlijk wel heel erg snel leeg. Misschien moeten we een soort OpenSource uurloon definieren ? Of kiezen we voor project financiering (lijkt mij beter). Wie wordt de juridische opdrachtgever, en wie gaat de resultaten beoordelen op kwaliteit, en daarmee de betalingen fiatteren ?? Komt er per project een programma van eisen ?? We zijn allemaal van goede wil, maar we moeten daar wel afspraken over maken en ons daaraan houden. Gert Gremmen -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Martijn van Exel Verzonden: maandag 11 februari 2008 22:17 Aan: Talk Openstreetmap CC: OpenStreetMap BE discussion list; [EMAIL PROTECTED] Onderwerp: [OSM-talk-nl] EUR 15K grant for software development Hi all, Back in November '07 I raised the issue of most pressing software development issues [1]. The objective was to give body to a proposal we were preparing for NLNet [2], which would include a grant for software development. The resulting discussion on talk / dev and discussion within the Dutch chapter led to a proposal submitted on Dec. 1st. The proposal is in Dutch and encompasses much more than the software development. It is available here [3]. Last month NLNet granted our request for funding -- at least, the software development part. So now we have EUR15k to spend on various development projects! Great, huh? This is how we think we should proceed: 1. I'll set a page up on the Wiki up to enable us to finetune the projects we're going to be supporting (asap). Starting point will be the central issues outlined in the proposal: a. Monitoring and Rollback b. Mobile Editor c. 'Map annotation for the rest of us' 2. We'll have a review period to finalize the project definitions. This can't last too long, NLNet wants to see progress. Two weeks max. 3. After the review, I submit the definitive project plans to NLNet for approval. 4. On approval, anyone (individual or group) would be able bid on the projects. After that, we agree on who's doing what and we can start implementation. NLNet will require close monitoring, a transparent process, definition of milestones and progress reports throughout the year. This will be an excellent opportunity to catalyse some of the OSM development projects, don't you agree? Let's hear your thoughts on this, I'll let you know when the wiki is done. On behalf of the Dutch chapter, Take care, Martijn [1] http://lists.openstreetmap.org/pipermail/talk/2007-November/020409.html [2] http://nlnet.nl/ [3] http://www.xs4all.nl/~exel0/osm/OSM%20subsidieaanvraag%202008.rtf -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsroutenetwerk-punten automatiseren?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Steven te Brinke schreef: Zelf ben ik wat aan het spelen geweest met al het water in Nederland, wat een 100 MB groot XML bestand oplevert. Java kon de DOM niet laden als ik Java 400MB geheugen gaf, omdat de DOM met alle handige referenties voor nogal wat overhead zorgt. Dus nu laad ik alles met een XML pull parser, wat veel beter gaat. Tevens zou ik een bounding box bepalen voor het gebied wat je wilt bekijken, bijvoorbeeld Zuid Nederland, en alle punten die daar buiten vallen meteen weg gooien. Dat scheelt ook weer geheugen. Je moet sowieso zorgen dat alles in je geheugen past, als je pc gaat swappen wordt het zo traag dat je beter een andere oplossing kunt zoeken. Heb je wat je wilt doen al eens geprobeerd met expat of msxml? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHsLkyYH1+F2Rqwn0RCjECAKCVS/bEEEy8QOe4vzWf8RGJjXUgEwCggYm7 k8fOo/XbLywDWxnOBpgy6wM= =y6s9 -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsroutenetwerk-punten automatiseren?
On Tue, 12 Feb 2008 02:17:14 +0100 Joris Meijerink [EMAIL PROTECTED] wrote: Dit zijn alle highways in Nederland (en stukjes Duitsland en België) die gisteren in de database zaten van het type: * primary * secondary * tertiary * unclassified * unsurfaced * track * residential * living_street * service * cycleway * pedestrian Volgens mij zijn dat alle type wegen waar je met een normale fiets of mountainbike wil komen. Pedestrian zit alleen maar in de lijst omdat AND tracks zo heeft getagged en die nog niet allemaal gecorrigeerd zijn.\ Klopt toch niet helemaal, er zijn ook nodes die alleen een AND tag hebben en geen highway tag, maar zijn soms wel degelijk een weg. De ander kant op zou beter werken, dus geen rail, geen landuse enz., heb alleen geen ideeof dat ook kan. De selectie kijkt naar de tags op de ways, niet naar die op de nodes. Het neemt simpelweg alle nodes die onderdeel zijn van (minstens) één van de geselecteerde ways. De laatste node in het bestand is bijvoorbeeld een amenity=parking en heeft zelf helemaal geen highway tag. Volgens mij is het zelfs zo dat bovenstaande waarden voor de highway tag alleen zinvol zijn op ways en niet op nodes. De enige (land)wegen die ik ooit heb gezien zonder highway tag waren FIXME previously unwayed segments (of zoiets) en die lagen allemaal in het buitenland :) Groetjes, Cartinus ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] EUR 15K grant for software development
On Tue, 12 Feb 2008, Gert Gremmen wrote: Misschien moeten we een soort OpenSource uurloon definieren ? Of kiezen we voor project financiering (lijkt mij beter) Ja, bounty systeem wil ook nog wel eens positieve stimulans opleveren. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsroutenetwerk-punten automatiseren?
Dit zijn alle highways in Nederland (en stukjes Duitsland en België) die gisteren in de database zaten van het type: * primary * secondary * tertiary * unclassified * unsurfaced * track * residential * living_street * service * cycleway * pedestrian Volgens mij zijn dat alle type wegen waar je met een normale fiets of mountainbike wil komen. Pedestrian zit alleen maar in de lijst omdat AND tracks zo heeft getagged en die nog niet allemaal gecorrigeerd zijn.\ Klopt toch niet helemaal, er zijn ook nodes die alleen een AND tag hebben en geen highway tag, maar zijn soms wel degelijk een weg. De ander kant op zou beter werken, dus geen rail, geen landuse enz., heb alleen geen ideeof dat ook kan. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Enschede Party
Aanvulling: Ik neem hoe dan ook de voorraad GPS-ontvangers mee die ik nog thuis heb. Zie de Wiki voor een lijst [1] Aanvulling 2: het lijkt me enorm leuk om ook eens een mapping video te maken van een party, zoals hier [2]. Gaaf toch?! Wie heeft de software / kennis hiervoor? Het schijnt dat dit de weg is: [3] [1] http://wiki.openstreetmap.org/index.php/GPS_Devices_OSM_Netherlands [2] http://www.youtube.com/watch?v=MoXru08B6Ss [3] http://wiki.openstreetmap.org/index.php/Party_render -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ Op 11 feb 2008, om 16:20 heeft Martijn van Exel het volgende geschreven: Ha allen, Komend weekend zijn een aantal van ons in Enschede voor een technische meeting. Het idee was om dit te combineren met wat mapping effort. Wie heeft zin om dit verder te organiseren? Het is vooral een kwestie van locatie, mensen warm maken en eventueel van tevoren wat geschikte gebieden uitzoeken (er is al een discussie op de Wiki[1] en een TODO- list[2]). Helemaal mooi zou zijn als er wat lokale en regionale pers gemobiliseerd zou kunnen worden. [1] http://wiki.openstreetmap.org/index.php/Netherlands_Mapping_Parties_2008#Enschede_en_omstreken [2] http://wiki.openstreetmap.org/index.php/Enschede#Todo- list_Enschede -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Talk-nl Digest, Vol 12, Issue 16
On Feb 9, 2008 8:16 PM, Martijn van Exel [EMAIL PROTECTED] wrote: Ecomare heeft software laten ontwikkelen die op allerlei manieren (her)gebruikt kan worden. Ik zag meteen een parallel met onze wens om een makkelijk te gebruiken 'field editor' te hebben voor OSM. Beetje on-origineel, maar: +1! Christ -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Enschede Party
Ik zal ook nog even m'n voorraad GPS-ontvangers meenemen. Zal proberen er voor die tijd nog even de laatste versie van de kaart erop te zetten. Kunnen we tijdens het mappen tenminste zien wat er nog niet op staat ;-) Stoer zo'n filmpje. Nu is Python niet m'n ding, maar dit is wel leuk om er even in te duiken. Nu nog even wat tijd hiervoor claimen :-[ Maarre, wat is de locatie precies? Was dat niet JR-online? Enne wanneer zijn we welkom? Gr, Henk Martijn van Exel schreef: Aanvulling: Ik neem hoe dan ook de voorraad GPS-ontvangers mee die ik nog thuis heb. Zie de Wiki voor een lijst [1] Aanvulling 2: het lijkt me enorm leuk om ook eens een mapping video te maken van een party, zoals hier [2]. Gaaf toch?! Wie heeft de software / kennis hiervoor? Het schijnt dat dit de weg is: [3] [1] http://wiki.openstreetmap.org/index.php/GPS_Devices_OSM_Netherlands [2] http://www.youtube.com/watch?v=MoXru08B6Ss [3] http://wiki.openstreetmap.org/index.php/Party_render ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Tele Atlas introduceert gps-kaarten voorvoetgangers
Op 11 feb 2008, om 10:07 heeft Gert Gremmen het volgende geschreven: Dat kunnen wij helemaal niet beter. Ja misschien de software, maar onze kaarten zijn evenmin geschikt voor voetgangers als die van teleatlas. Hier moet nog ontzettend veel mapwerk verricht worden. We weten niet hoe goed de data van TA feitelijk is op dat gebied. Mijn opmerking was dan ook meer bedoeld als aansporing! Er zijn misschien nog wel meer voetpaden dan wegen, en dan heb ik het nog niet over immense aantallen doorsteekjes tussen straten, door parken en gebouwen, die essentieel zijn voor een goede stappenplanner. Precies. Ik weet niet of er überhaupt al goede en betrouwbare voorbeelden zijn van een routeplanner voor voetgangers. Je hebt enorm veel lokale kennis nodig. Ideaal voor een project als OSM. Het wordt weer mooi weer, staat er al een nieuwe mapping party in de pipeline ?? Organiseer het! Het is echt weinig werk en het levert veel op. Zie hier voor ideeën e.d.: http://wiki.openstreetmap.org/index.php/Netherlands_Mapping_Parties_2008 -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Artikel in Leeuwarder Courant naar aanleiding persbericht Friese kaart
Zoran Kovacevic wrote: Leuk artikel! Ik zie in de stats dat er gelinkt wordt vanaf de home van www.friesland.nl :) Dat is mooi, 'k hoop dat er nog wat nieuwe gebruikers bijkomen uit die hoek. Deze kop snap ik trouwens niet: http://www.dutchcowboys.nl/local/12761/fromfeed/1 Heh, ik ook niet... ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] Artikel in Leeuwarder Courant naar aanleiding persbericht Friese kaart
In de Leeuwarder Courant (grootste regionale krant in Friesland) heeft in het katern Regio een ruim artiekel gestaan naar aanleiding van het Friestalige kaart persbericht. Zij waren zo vriendelijk om een exemplaar op te sturen en ik heb er even een scan gemaakt. Het paste maar net op de scanner, dus de linker- en rechterkant zijn niet al te mooi geworden: http://download.na1400.info/osm/LC-20080205.pdf Openen met Acrobat Reader en dan tegen de klok in draaien (SHIFT CTRL -) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Tele Atlas introduceert gps-kaarten voorvoetgangers
Dat kunnen wij helemaal niet beter. Ja misschien de software, maar onze kaarten zijn evenmin geschikt voor voetgangers als die van teleatlas. Hier moet nog ontzettend veel mapwerk verricht worden. Er zijn misschien nog wel meer voetpaden dan wegen, en dan heb ik het nog niet over immense aantallen doorsteekjes tussen straten, door parken en gebouwen, die essentieel zijn voor een goede stappenplanner. Misschien is er op korte termijn iets te maken Voor de wandelaar, maar niet als aanvulling op bijvoorbeeld de auto: Je parkeert in een buurt en de laatste 200 meter Steek je die omweg/eenrichtingsstraat/bussluis af door een steegje. Die steegjes hebben we gewoon nog niet. Dat geldt trouwens voor veel meer aspecten van de kaart. Het wordt weer mooi weer, staat er al een nieuwe mapping party in de pipeline ?? Gert Gremmen -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Martijn van Exel Verzonden: maandag 11 februari 2008 9:22 Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] Tele Atlas introduceert gps-kaarten voorvoetgangers Leuke ontwikkeling, die ik plaats in de context van de 'dreiging' van vrije overheidsdata. Dit is een manier om nieuwe markten aan te boren. Toerisme lijkt me een voor de hand liggende in dit verband. Wij kunnen dit trouwens beter, uiteraard. -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ Op 8 feb 2008, om 18:23 heeft Joris Meijerink het volgende geschreven: Ze zijn hun markt ook aan het vergroten. http://life.tweakers.net/nieuws/51771/tele-atlas-introduceert-gps-kaarte n-voor-voetgangers.html ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Tele Atlas introduceert gps-kaarten voor voetgangers
Leuke ontwikkeling, die ik plaats in de context van de 'dreiging' van vrije overheidsdata. Dit is een manier om nieuwe markten aan te boren. Toerisme lijkt me een voor de hand liggende in dit verband. Wij kunnen dit trouwens beter, uiteraard. -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ Op 8 feb 2008, om 18:23 heeft Joris Meijerink het volgende geschreven: Ze zijn hun markt ook aan het vergroten. http://life.tweakers.net/nieuws/51771/tele-atlas-introduceert-gps-kaarten-voor-voetgangers.html ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Tele Atlas introduceert gps-kaarten voor voetgangers
2008/2/8 Joris Meijerink [EMAIL PROTECTED]: Ze zijn hun markt ook aan het vergroten. http://life.tweakers.net/nieuws/51771/tele-atlas-introduceert-gps-kaarten-voor-voetgangers.html Dat is niet zo vreemd. De vraag daarnaar wordt ook groter. Ook moet je vaak enorm omlopen volgens de route die een auto-navigatiesysteem je voorschoteld, terwijl je met een kwart van de afstand lopend je doel kan bereiken. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsroutenetwerk-punten automatiseren?
Nu we het toch over ways en nodes hebben. Die ways zelf heb je natuurlijk niet nodig tijdens het zoeken naar de dichtsbijzijnde node: http://www.xs4all.nl/~tibors/Temp/dutch-road-nodes.osm.gz bevat alleen de nodes uit het eerder vermelde bestand. Nog maar 279MB uitgepakt. m.v.g. Cartinus On Tue, 12 Feb 2008 02:58:11 +0100 Martijn Verwijmeren [EMAIL PROTECTED] wrote: On Tue, 12 Feb 2008 02:17:14 +0100 Joris Meijerink [EMAIL PROTECTED] wrote: Dit zijn alle highways in Nederland (en stukjes Duitsland en België) die gisteren in de database zaten van het type: * primary * secondary * tertiary * unclassified * unsurfaced * track * residential * living_street * service * cycleway * pedestrian Volgens mij zijn dat alle type wegen waar je met een normale fiets of mountainbike wil komen. Pedestrian zit alleen maar in de lijst omdat AND tracks zo heeft getagged en die nog niet allemaal gecorrigeerd zijn.\ Klopt toch niet helemaal, er zijn ook nodes die alleen een AND tag hebben en geen highway tag, maar zijn soms wel degelijk een weg. De ander kant op zou beter werken, dus geen rail, geen landuse enz., heb alleen geen ideeof dat ook kan. De selectie kijkt naar de tags op de ways, niet naar die op de nodes. Het neemt simpelweg alle nodes die onderdeel zijn van (minstens) één van de geselecteerde ways. De laatste node in het bestand is bijvoorbeeld een amenity=parking en heeft zelf helemaal geen highway tag. Volgens mij is het zelfs zo dat bovenstaande waarden voor de highway tag alleen zinvol zijn op ways en niet op nodes. De enige (land)wegen die ik ooit heb gezien zonder highway tag waren FIXME previously unwayed segments (of zoiets) en die lagen allemaal in het buitenland :) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Scriptje om tiles te downloaden en aaneen te plakken
Johan Huysmans wrote: Dit is wat je nodig hebt: http://tah.openstreetmap.org/MapOf/ Ik ben op zoek naar iets waar 'k kan instellen dat 'k de output in 300 dpi wil. Kan dat daar ook mee? Of is het enkel voor schermoutput/webdoeleinden? Jo ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsroutenetwerk-punten automatiseren?
ben nu op de 917MB grote osm file aan het knauwen maar dat schiet niet echt op vooral ook omdat m'n intern geheugen maar 1gig is. Ben nu kijken of ik de file doomidden knip, of dat ik het via sax ga parsen.. Op 11-02-08 heeft Joris Meijerink [EMAIL PROTECTED] het volgende geschreven: Ik ben benieuwd hoe het gaat? ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsroutenetwerk-punten automatiseren?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Steven te Brinke schreef: Wat zijn de voordelen hiervan? Ik kan me voorstellen dat het snellere parsers zijn; nu gaat het niet heel snel maar ik vind een halve minuut nog best acceptabel. Ik kan me niet voorstellen dat ze veel minder geheugen gebruiken als ze dezelfde datastructuur maken (DOM). Dus ik zie niet in dat ze het geheugenprobleem op kunnen lossen. Verder lijkt het mij geen probleem als een programma voor een eenmalige import nogal lang nodig heeft om te draaien. Zelfs als ik het een uur zou moeten laten draaien, zou ik daar geen problemen mee hebben. Het is toch eenmalig. Als je echter te weinig geheugen beschikbaar hebt, gaat dit niet lukken. Dus daar zul je iets aan moeten. Persoonlijk gaat mijn voorkeur nog altijd uit naar Java, omdat ik daarin veel sneller een programma kan schrijven. Maar voor de c kenners is een iets snellere implementatie in c natuurlijk wel een goede keuze. Expat en MSXML zijn op hun eigen gebied waarschijnlijk de snelste parsers die beschikbaar zijn. Voor een eenmalige optie maakt het natuurlijk niet uit, maar zelfs een eenmalige import wordt vaker dan 1x gedraaid. Maar goed doe vooral waar je zelf het beste mee om kunt gaan, zodra je tegen limitaties gaat lopen zijn er dus nog alternatieven. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHsO5yYH1+F2Rqwn0RCt70AKCQRUYyUPaT6nnkVeF5VmWeWTywCQCfRscS mUeT2P8uXiavQBs/Iu863X8= =L9ke -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsroutenetwerk-punten automatiseren?
On Mon, 11 Feb 2008 17:15:30 +0100 Rob [EMAIL PROTECTED] wrote: ben nu op de 917MB grote osm file aan het knauwen maar dat schiet niet echt op vooral ook omdat m'n intern geheugen maar 1gig is. Ben nu kijken of ik de file doomidden knip, of dat ik het via sax ga parsen.. Doormidden knippen kan denk ik een stukje intelligenter. http://www.xs4all.nl/~tibors/Temp/dutch-roads.osm.gz Dit zijn alle highways in Nederland (en stukjes Duitsland en België) die gisteren in de database zaten van het type: * primary * secondary * tertiary * unclassified * unsurfaced * track * residential * living_street * service * cycleway * pedestrian Volgens mij zijn dat alle type wegen waar je met een normale fiets of mountainbike wil komen. Pedestrian zit alleen maar in de lijst omdat AND tracks zo heeft getagged en die nog niet allemaal gecorrigeerd zijn. Ik denk dat je wil dat alle fietsknooppunten onderdeel van één van deze wegen worden en niet vastzitten aan bijvoorbeeld een landuse polygoon of de gemeentegrens. Als de bestandsgrootte (nu 552MB) verhouding namelijk representatief is voor de hoeveelheid nodes zou namelijk 40% van de knooppunten alsnog moeten worden verplaatst als je ze vast maakt aan een willekeurige node. Groetjes, Cartinus P.S. Niet meteen downloaden, de computer belooft over een minuut of 5 klaar te zijn met uploaden. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Scriptje om tiles te downloaden en aaneen te plakken
We hebben al eens een kaart van Amsterdam gemaakt op zoomlevel 16 voor een mapping party. Dat heeft Rob Aerts destijds gedaan. Ook is er eens een poster gemaakt van Nederland, ook daar zal wel automatiek aan te pas gekomen zijn. En er is ook nog Kosmos [1] mar dat is volgens mij geen stitcherscript maar een renderer. [1] http://igorbrejc.net/kosmoshome -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ Op 11 feb 2008, om 16:44 heeft Maarten Deen het volgende geschreven: Voor de mapping party in Mechelen had ik wat tiles gedownload en die met Imagemagick aan elkaar geplakt. Dat is natuurlijk perfect te automatiseren. Is daar al een scriptje voor of zal ik die even maken? Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Artikel in Leeuwarder Courant naar aanleiding persbericht Friese kaart
Leuk artikel! Ik zie in de stats dat er gelinkt wordt vanaf de home van www.friesland.nl :) Deze kop snap ik trouwens niet: http://www.dutchcowboys.nl/local/12761/fromfeed/1 On 11 feb 2008, at 10:38, Lambertus wrote: In de Leeuwarder Courant (grootste regionale krant in Friesland) heeft in het katern Regio een ruim artiekel gestaan naar aanleiding van het Friestalige kaart persbericht. Zij waren zo vriendelijk om een exemplaar op te sturen en ik heb er even een scan gemaakt. Het paste maar net op de scanner, dus de linker- en rechterkant zijn niet al te mooi geworden: http://download.na1400.info/osm/LC-20080205.pdf Openen met Acrobat Reader en dan tegen de klok in draaien (SHIFT CTRL -) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl -- http://www.kovacevic.nl/blog ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Tele Atlas introduceert gps-kaarten voorvoetgangers
Interessant voor zover ze publiek toegankelijk zijn en relaties in het stratennetwerk representeren. Dus een doodlopend steegje waar geen adressen aan liggen wellicht niet, een steegje tussen twee huizen dat twee straten verbindt dan weer wel. -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ Op 11 feb 2008, om 12:58 heeft Joris Meijerink het volgende geschreven: Dat kunnen wij helemaal niet beter. Ja misschien de software, maar onze kaarten zijn evenmin geschikt voor voetgangers als die van teleatlas. Hier moet nog ontzettend veel mapwerk verricht worden. We weten niet hoe goed de data van TA feitelijk is op dat gebied. Mijn opmerking was dan ook meer bedoeld als aansporing! Delft staat er al wel best aardig in: http://www.tile.openstreetmap.nl/?zoom=15lat=52.01161lon=4.35949layers=B00F Maar ja tot hoever wil je gaan met die steegjes, lijkt me dat steegjes naar iemands achtertuin niet nuttig zijn ook al zou je die wel op een kaart kunnen zien. gr Joris it wasn't me Meijerink ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Talk-nl Digest, Vol 12, Issue 16
Bedankt, ik hoor graag alle feedback! Ik zal ze eens contacten voor een oriënterend gesprek. -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ Op 11 feb 2008, om 15:03 heeft Christ van Willegen het volgende geschreven: On Feb 9, 2008 8:16 PM, Martijn van Exel [EMAIL PROTECTED] wrote: Ecomare heeft software laten ontwikkelen die op allerlei manieren (her)gebruikt kan worden. Ik zag meteen een parallel met onze wens om een makkelijk te gebruiken 'field editor' te hebben voor OSM. Beetje on-origineel, maar: +1! Christ -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] Scriptje om tiles te downloaden en aaneen te plakken
Voor de mapping party in Mechelen had ik wat tiles gedownload en die met Imagemagick aan elkaar geplakt. Dat is natuurlijk perfect te automatiseren. Is daar al een scriptje voor of zal ik die even maken? Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [Talk-de] Relations für Teilwege
Am Montag, 11. Februar 2008 schrieb Christoph Eckert: Moin, 'nabend ich habe just gestern versucht, meine erste Radroute als Relation anzulegen. Dabei hatte ich auch das Problem, dass ich einige Wege an äußerst ungeschickten Stellen teilen musste. Naja, ich finde Kreuzungen gar nicht so unpraktisch um Wege zu zerteilen. Dann hätten wir aber mit zunehmendem Detaillierungsgrad immer kürzere Wegstückelchen (Segmente durch die Hintertür) fände ich nicht so schlimm. Passiert ja eh hin und wieder, weil sich irgendwelche anderen Eigenschaften ändern, wie z. B. die Oberflächenbeschaffenheit oder die Breite. und müssten ständig die Relations nachpflegen. Naja, da könnte man ja theoretisch die Editoren verbessern. Dass beim Aufspalten eines Weges, der zu einer Relation gehört danach beide Wege in der Relation stecken wäre z. B. ein super Anfang, gar kein soo großer Aufwand und schon müsste man nicht mehr viel von Hand nachpflegen, oder? Oder man lässt Wege an größeren Stücken und beschreibt Routen (und eben Attribute) auf Teilen dieses Weges über Relationen. Ich finde irgendwie die letzte Vorgehensweise besser, ohne dass ich es begründen könnte. Ich verstehe nicht ganz wie du das meinst. Eine Relation die besagt Weg 3 hat zwischen Knoten 32423 und 32451 die Breite 4m und dann eben den Weg und die Knoten relationiert? Finde ich nicht so praktisch, aber auch mehr der Nase nach geredet, ohne es sauber begründen zu können. Rapha ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Relations für Teilwege
Hallo, Es gibt demzufolge wohl fünf Segmente der Bahnhofsstraße, die nun alle einzeln umbenannt werden müssten? Ja. (Wobei ein versierter Mapper natuerlich einfach in JOSM alle Bahnhofsstraßen selektiert, evtl. sogar durch eine Suche, und sie dann in einem Handstreich aendert. In der Datenbank werden aber fuenf Aenderungen draus.) Wie schon erwaehnt wurde, war der Plan, dieses Problem mit Superways langsam zu entschaerfen, aber es gibt sicher auch viele andere Moeglichkeiten. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Individuelle Online-Karte - 2. Versuch ist online
So, die Sache mit den Koordinaten funktioniert jetzt :) Hast Du den IE? Mit dem geht es (noch) nicht. der laeuft hier nicht ;-) ich hab's mit dem konqueror versucht. mit firefox klappts... Ich hatte ein paar Semikolons am Zeilenende vergessen, da ist der Firefox offensichtlich sehr tolerant :) aber leider funktioniert die Seite mit dem IE immer noch nicht. Wie sieht's mit dem Konqueror aus? Falls es nicht klappt: hat er einen Javascript-Debugger, den Du befragen könntest? Paul ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Relations für Teilwege
Hi, ich habe just gestern versucht, meine erste Radroute als Relation anzulegen. Dabei hatte ich auch das Problem, dass ich einige Wege an äußerst ungeschickten Stellen teilen musste. Naja, ich finde Kreuzungen gar nicht so unpraktisch um Wege zu zerteilen. finde ich grundsätzlich auch, sofern es um einfache Straßenkreuzungen geht. Ich hatte aber dann so Fälle wo ich eine Residential an einer Kreuzung in mehrer kurze Teile hacken musste, weil da auf der einen Seite ein Radweg parallel lief. Grundsätzlich nicht falsch, aber ich fand es blöd die Residential zuhacken zu müssen nur weil der Härr Eckert meint dass er da jetzt eine Radroute mappen müsste. [...] und müssten ständig die Relations nachpflegen. Naja, da könnte man ja theoretisch die Editoren verbessern. Dass beim Aufspalten eines Weges, der zu einer Relation gehört danach beide Wege in der Relation stecken wäre z. B. ein super Anfang, gar kein soo großer Aufwand und schon müsste man nicht mehr viel von Hand nachpflegen, oder? Yo. Sobald sich mal ein paar Standardrelations herauskristallisiert haben werden wird es auch solche Features geben. Nachteil der Relations ist halt dass man die nicht so schön sieht. Es ist nicht sofort erkenntlich, ob ein Objekt in einer oder gar mehreren Relations steckt. Besonders letzteres wird bestimmt noch lustig :) . Oder man lässt Wege an größeren Stücken und beschreibt Routen (und eben Attribute) auf Teilen dieses Weges über Relationen. Ich finde irgendwie die letzte Vorgehensweise besser, ohne dass ich es begründen könnte. Ich verstehe nicht ganz wie du das meinst. Eine Relation die besagt Weg 3 hat zwischen Knoten 32423 und 32451 die Breite 4m und dann eben den Weg und die Knoten relationiert? Beispielsweise, und ich finde eine solche Vorgehensweise beispielsweise für Straßen, die (vielleicht auch nur auf einem Teilstück) Einbahnstraßen sind wesentlich besser als die momentane Einbahnstraßenregelung, die sich an der Richtung des Weges orientiert. Finde ich nicht so praktisch, aber auch mehr der Nase nach geredet, ohne es sauber begründen zu können. Wie gesagt, wenn an einer Straße ein Sack Relations hängt wird sie irgendwann schwierig zu editieren, weil man dann nach die ganzen Relations nachziehen muss. Aber das wird die Zukunft zeigen. Schönen Abend, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Bayern
Martin Trautmann schrieb: Hallo, für etwa 1700 Straßen in Bayern hätte ich Korrekturvorschläge zur Schreibweise. Nicht alles davon muss richtig sein. Manches ist auch einfach nur gleich gut - ich bevorzuge eben die lange Schreibweise, wo manchen ein v. statt von reicht. Großes Dankeschön, werde die Änderungen in meiner Region in Erwägung ziehen und evtl. nochmal auf die Schilder vor Ort schauen Jannis smime.p7s Description: S/MIME Cryptographic Signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Individuelle Online-Karte - 2. Versuch ist online
Am Montag 11 Februar 2008 schrieb Paul Lenz: So, die Sache mit den Koordinaten funktioniert jetzt :) Hast Du den IE? Mit dem geht es (noch) nicht. der laeuft hier nicht ;-) ich hab's mit dem konqueror versucht. mit firefox klappts... Ich hatte ein paar Semikolons am Zeilenende vergessen, da ist der Firefox offensichtlich sehr tolerant :) aber leider funktioniert die Seite mit dem IE immer noch nicht. Wie sieht's mit dem Konqueror aus? Falls es nicht klappt: hat er einen Javascript-Debugger, den Du befragen könntest? ne, tut immer noch nicht. beim ersten mal heissts wieder waiting for poi-data und nach 'ner zeit kommt ein timeout. bei weiterem schieben/waehlen/zoomen kommt der timeout sofort. javascript-debugger? keine ahnung, nicht dass ich wuesste... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Relations für Teilwege
Am Montag, 11. Februar 2008 schrieb Martin Trautmann: Es gibt demzufolge wohl fünf Segmente der Bahnhofsstraße, die nun alle einzeln umbenannt werden müssten? Naja, wenn der Namen in einem Superway stecken würde wäre das kein Problem. Ich fände aber den Ansatz, dass der Editor fragt ob er die Änderungen auch für die n aneinanderhängenden Wegen - die die gleiche Eigenschaften haben - auch eine gute Lösung. - Komme aber mit JOSM auch ganz gut zurecht, weil ich nach Bahnhofsstraße suchen kann und und dann alle markierten Wege auf einen Schlag ändere. Rapha ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Relations für Teilwege
Frederik Ramm wrote: Also, immer mal langsam. Das mit dem Zerschnipseln ist schon immer so gewesen. Es ist zwar nur ein Teilaspekt. Aber mal ein Beispiel dazu: Beim Abgleich mit opengeodb-Straßenverzeichnissen habe ich für Bayern etwa 1700 Korrekturvorschläge für Straßennamen gefunden. Für Oberbayern und Niederbayern hatte ich detailliertere Statistiken erstellt und entsprechend auch die Korrekturvorschläge eingespielt: http://wiki.openstreetmap.org/index.php/Talk:Niederbayern#KEH:_Kelheim In Kelheim sollte vielleicht die Bahnhofsstraße in Bahnhofstraße umbenannt werden. 1.4 KEH: Kelheim * #4712337 Bahnhofsstraße; Bahnhofstraße; 09273137; 93309; KELHEIM * #4712338 Bahnhofsstraße; Bahnhofstraße; 09273137; 93309; KELHEIM * #8599673 Bahnhofsstraße; Bahnhofstraße; 09273137; 93309; KELHEIM * #8599674 Bahnhofsstraße; Bahnhofstraße; 09273137; 93309; KELHEIM * #8599762 Bahnhofsstraße; Bahnhofstraße; 09273137; 93309; KELHEIM Es gibt demzufolge wohl fünf Segmente der Bahnhofsstraße, die nun alle einzeln umbenannt werden müssten? Konkret ist an der Stelle das Problem evtl. schon behoben - mit Potlatch kann ich da wenig erkennen. Da ich rein auf den .osm-Daten arbeitete, gab es recht häufig solche Effekte. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Worldfile vom 6.2.08
Hallo Holger, bei mir geht das DE- File auch nicht in Mapsource. Ich kann das immer nur sehr zeitverzögert testen, da ich sonst überall nur Linux habe. Warum das so ist weiss ich allerdings auch nicht.(Also warum die Deutschlandkarte nicht geht, nicht warum ich überall Linux habe. ;-) Da die Kacheln die gleichen sind. Der Unterschied ist nur die Übersichtskarte und das tdb- File. Holger Schrader schrieb: Sorry, aber auch das Deutschland Worldfile 06.02.2008 funktioniert bei mir nicht im MapSource. -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Worldfile vom 6.2.08
Hallo Carsten, Sorry, aber auch das Deutschland Worldfile 06.02.2008 funktioniert bei mir nicht im MapSource. Mein Reg. Eintrag sieht so aus: REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Garmin\MapSource\Products\DE] LOC=C:\\Garmin\\DE\\ BMAP=C:\\Garmin\\DE\\6323.img TDB=C:\\Garmin\\DE\\6323.tdb Die Worldfiledaten liegen im C:\Garmin\DE Ordner. Ist das Problem nur bei mir oder auch bei anderen Usern. In der Liste meldet sich nämlich niemand der auch diese Problem hat. Das Wordfile WELT funktioniert. Ciao Holger Carsten Schwede schrieb: Hallo, das neue Worldfile steht wieder zum Download zur Verfügung. http://wiki.openstreetmap.org/index.php/User:Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Bayern
Martin Trautmann schrieb: Hallo, für etwa 1700 Straßen in Bayern hätte ich Korrekturvorschläge zur Schreibweise. Nicht alles davon muss richtig sein. Manches ist auch einfach nur gleich gut - ich bevorzuge eben die lange Schreibweise, wo manchen ein v. statt von reicht. Ich übernehme das was auf dem Straßenschild steht, vor allem wenn es konsistent auf allen gefundenen Schildern gleich ist. Auf http://wiki.openstreetmap.org/index.php/Talk:Bavaria finden sich die restlichen Vorschläge. Oberbayern und Niederbayern besitzen eigene Teilauswertungen: http://wiki.openstreetmap.org/index.php/Talk:Oberbayern ist recht umfangreich, Ich habe meine Typos korrigiert und gekennzeichnet. Allerdings hat sich eine Straße in den falschen Ort verirrt: die 'Riegerau Straße' ist in Langenbach nicht in Marzling. In Zolling ist die OSM-Schreibweise 'Muggenthaler Straße' richtig. Ist vermerkt. Vielen Dank für deine Mühe. Gruss mikes ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Bayern
Hi, Großes Dankeschön, werde die Änderungen in meiner Region in Erwägung ziehen und evtl. nochmal auf die Schilder vor Ort schauen den Schildern würde ich keine allzu hohe Priorität einräumen. Auf selbigen werden manchmal Straßennamen abgekürzt, weil das Schild eben nicht lang genug war. Umlaute werden schonmal ausgeschrieben, vielleicht weil die verwendete Software damals noch keine Unlaute konnte (und nein, ich meine jetzt nicht die Goethestraße ;-) . Straße schreibt sich auch nach neuer Rechtschreibung noch immer mit sz. Ich bin auch schon auf Straßen unterwegs gewesen, in denen die Namen auf unterschiedlichen Schildern verschieden geschrieben waren. Mag wohl daran gelegen haben dass Sie von unterschiedlichen Schriftsetzern gefertigt wurden. Was ich sagen will ist dass man sich beim Mappen nicht sklavisch an die Schilder halten, sondern im Bedarfsfalle einfach seine Deutschkenntnisse bemühen sollte. Beste Grüße, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Bayern
Hallo, für etwa 1700 Straßen in Bayern hätte ich Korrekturvorschläge zur Schreibweise. Nicht alles davon muss richtig sein. Manches ist auch einfach nur gleich gut - ich bevorzuge eben die lange Schreibweise, wo manchen ein v. statt von reicht. Auf http://wiki.openstreetmap.org/index.php/Talk:Bavaria finden sich die restlichen Vorschläge. Oberbayern und Niederbayern besitzen eigene Teilauswertungen: http://wiki.openstreetmap.org/index.php/Talk:Oberbayern ist recht umfangreich, http://wiki.openstreetmap.org/index.php/Talk:Niederbayern ist recht knapp. Das Wiki ist nicht unbedingt der richtige Ort für solche Übersichten - da rutscht man schnell über 32 k Seitengröße, von schon aufgetretenen Seiten, die jenseits von 200 k komplett explodierten, ganz zu schweigen. Ich selbst bin nicht in der Lage, solche Massen an Korrekturen einzupflegen. Wenn jemand aber die Daten gerne anders aufbereitet haben möchte, helfe ich gerne soweit möglich weiter. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Relations für Teilwege
Hallo, Will man z.B. einer Straße nachträglich noch ein Atribut geben muß man alle Teile zusammensuchen. Danach geht man dann mit Relations wieder hin um Teile zusammenzufassen. Was wiederum zu Problemen führt wenn eines der Member nachträglich zerschnitten wird, wie vor kurzem berichtet. Wäre es nicht praktischer wenn man den umgekehrten Weg geht. Also möglichst eine Straße = ein way. Will man dann Tempo 50 für das Teilstück der Hauptstraße von Node xyz4 bis Node xyz7 setzen so zerschneidet man die Hauptstraße nicht an den beiden Nodes sondern macht eine Relation: way=Hauptstraße start=xyz4 end=xyz7 maxspeed=50 Haben wir diesen vorschlag eigentlich schon besprochen? Ich war auch ziemlich überrascht, als ich zum ersten mal von dem zerschnipseln hörte. Segmente durch die hintertür... Aber nun ist es wohl erstmal zu spät. Also, immer mal langsam. Das mit dem Zerschnipseln ist schon immer so gewesen. Eine Zeit lang haben Leute versucht, das Zerschnipseln zu umgehen, indem sie ihre maxspeed=... oder sowas an die Segmente getaggt haben, als wir die noch hatten, aber das gab auch Chaos und hat einen auch nicht davor bewahrt, erstens alle betreffenden Segmente zusammensuchen zu muessen, und zweitens kuenstlich Nodes zu setzen, nur um dort ein Segment mit anderem maxspeed beginnen zu lassen. Von Segmente durch die Hintertuer kann also keine Rede sein, das Problem gab es schon, als wir noch Segmente hatten. Ich dachte eigentlich zuerst, dass wir das Problem durch die sogenannten Superways loesen; wie oben richtig festgestellt, gibt es da noch Probleme beim Editieren, aber das ist ja nur was Voruebergehendes. Die Verwendung einer Relation als qualifiziertes Tag hatte ich fuer andere Sachen im Hinterkopf; ich dachte, man koennte damit sowas eintragen wie dieser Way ist Einbahnstrasse, aber nur fuer LKW oder so. Nun wird vorgeschlagen, Tags auf andere Weise zu qualifizieren, und zwar dieser Way ist Einbahnstrasse, aber nur von Node A bis Node B. Im Prinzip finde ich das eine gute Idee; eventuell koennte man das mit den angedachten Superways auch verbinden: * Eine Relation, die einen Way und zwei Nodes als Member hat, sagt aus, dass ein bestimmtest Tag auf dem Way von Node 1 bis Node 2 gilt. * Ebenso koennte eine solche Relation auch mehrere Ways als Member haben, gibt ja keine Notwendigkeit, das auf einen Way zu beschraen- ken; die Grenz-Nodes koennen optional weggelassen werden, wenn das Attribut fuer die ganze Strecke gilt. (Das waeren dann die Superways.) * Die Annhame, dass ein Attribut immer an einem Node beginnt und endet, ist eventuell eine ueberfluessige Einschraenkung; man koennte eventuell, wie bei GDF, auch zulassen, dass man eintraegt ab Position 800m bis Position 1200m auf dieser Strasse absolutes Halteverbot. Dann haette man allerdings wieder eine Richtungsab- haengigkeit. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Bayern
Michael Schmitt wrote: Allerdings hat sich eine Straße in den falschen Ort verirrt: die 'Riegerau Straße' ist in Langenbach nicht in Marzling. Danke, eine solche kenne ich noch nicht - ich habe nur Riegerau, Ortsteil Riegerau, in Marzling - wohl was einzeln stehendes. In Zolling ist die OSM-Schreibweise 'Muggenthaler Straße' richtig. Schwierige Sache - es gibt beide Schreibweisen und sowohl einen Dr. Muggenthaler als auch einen Ort Muggenthal. Da die Straße wohl nach dem Ort benannt scheint, passt die OSM-Schreibweise wohl. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Radverkehrsnetz NRW
Hallo! Da ich in den letzten Tagen mal einige Radwege meiner Umgebung (Bonn) ausgebaut und korrigiert habe, machte ich mir auch Gedanken über die Erfassung des Radverkehrsnetzes NRW, um es auf der OSM-Fahrradkarte (www.gravitystorm.co.uk/osm) erscheinen zu lassen. Die entsprechenden Wege würde Ich mit rcn=yes taggen. Nun gibt es hier ja inzwischen überall diese Fahrrad-Wegweiser des Radwegenetzes mit Ziel- und Kilometerangaben und die kleineren Schilder mit Richtungspfeilen, an denen man sich orientieren könnte. Diese bilden hier ein recht dichtes Netz, das einen quasi von jedem Dorf ins nächste leiten kann und auch weiter entfernte Ziele angibt. Ein kurzer Blick auf die offizielle Seite des Radwegenetzes(http://www.radverkehrsnetz.nrw.de/ nein, ich habe nicht vor, Informationen von dort zu verwenden!) zeigt aber ein sehr viel dünneres Netz. Weiß jemand, was da los ist? Gibt es ein Hauptnetz und Nebenstrecken? Oder ist deren Karte einfach total veraltet und unvollständig? Meint ihr, es lohnt sich, beim Landesministerium anzufragen, ob die Daten bereitstellen würden? Oder setzen wir uns damit nur deren argwöhnischer Beobachtung aus? Die Copyright-Hinweise der Karte/des Radroutenplaners(http://www.radroutenplaner.nrw.de/RRP_impress_02.html#nutzbed) sind ja deutlich - andererseits interessieren uns ja auch nur harte Fakten(Zugehörigkeit zum RVN ja/nein). Wenn sich aufgrund des schönen Wetters nun auch andere Rheinländer und Westfalen motiviert sehen, auf ihren Touren Notizen über das RVN NRW zu machen und die entsprechenden Strecken zu taggen, würde ich eine Wiki-Seite dazu eröffnen - wie sieht's aus? :-) -Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Beta: Shapefiles zum Download
Hallo, auf download.geofabrik.de biete ich jetzt auch naechtlich aktualisierte Shapefiles zum Download an, in der gleichen Stueckelung Grad mal drübergeschaut und folgende Anmerkungen: [...] Da fehlte in allen DBFs eine Spalte. Programmfehler ;-) ich lass' es gerade nochmal neu rechnen. Waterways in das Flaechen-File ist ne gute Idee. Oneway bei den Strassen hab ich drin (fehlte aufgrund des o.g. bugs), Maxspeed noch nicht, koennte man noch reintun, das stimmt. Straßen mit unbekannten Typen sollten weggelassen werden oder auf Typ unknown gesetzt oder so. Sonst hat man so viele Datenfehler drin, wo Leute Highway=Straßenname gesetzt haben oder so. Hm, mir waere lieber, in solchen Situationen die Quelldaten zu verbessern statt um Fehler in diesen Daten herumzubasteln. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Beta: Shapefiles zum Download
Hi! On Mon, Feb 11, 2008 at 10:21:07AM +0100, Frederik Ramm wrote: auf download.geofabrik.de biete ich jetzt auch naechtlich aktualisierte Shapefiles zum Download an, in der gleichen Stueckelung Grad mal drübergeschaut und folgende Anmerkungen: * natural: Attribut name sollte vielleicht type heissen * points: Kein Typ vorhanden, nur der Name * railways: Auch hier fehlt der Typ * roads: Maxspeed und Oneway wäre noch sinnvoll, Straßen mit unbekannten Typen sollten weggelassen werden oder auf Typ unknown gesetzt oder so. Sonst hat man so viele Datenfehler drin, wo Leute Highway=Straßenname gesetzt haben oder so. Ebenso muss natürlich oneway und maxspeed sauber gemacht werden. * waterways: Typ riverbank müßte eigentlich anders behandelt werden. Er gehört eigentlich zusammen mit natural=water in ein Polygon-File. Jochen -- Jochen Topf [EMAIL PROTECTED] http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Beta: Shapefiles zum Download
Hallo, auf download.geofabrik.de biete ich jetzt auch naechtlich aktualisierte Shapefiles zum Download an, in der gleichen Stueckelung wie die uebrigen OpenStreetMap-Daten, also nach diversen europaeischen Laendern sowie auch Einzelfiles fuer die deutschen Bundeslaender. Ich selber kein erfahrener Shapefile-Benutzer und waere daher auf Feedback bezueglich der Brauchbarkeit angewiesen, d.h. ob die Aufteilung der Files und die Attribute in den .dbf-Files so gut sind, oder ob man das besser anders machen sollte. Im Moment gibt es pro Bereich ein Zip-File, und darin dann je eine .shp/.shx/.dbf-Kombination fuer Strassen, Wasserwege, Eisenbahnen, POIs, Gebaeude, Waelder/Seen/Parks. Bei den POIs habe ich gnadenlos amenity, tourism, man_made zusammengeworfen. Also wenn irgendjemand von Euch routinemaessig mit Shapefiles umgeht, schaut Euch das doch mal an und sagt, ob man noch was verbessern sollte. Ich denke mal, jemand, der spezielle Anforderungen hat, kann sich ja immer ein eigenes Shapefile extrahieren aus den OSM-Daten, ich wollte hier bloss mal was anbieten zum Anfixen, damit Leute, die einfach OSM-Daten in ihr existierendes Tool reinwerfen wollen, etwas zum Spielen haben. WMS kommt auch demnaechst, weiss bloss noch nicht, wie am besten ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Treffen in München - Februar
das februar-treffen wird am 19.02. ab ca. 19 uhr im rila, balanstrasse 16 stattfinden. das ist (bisher) noch kein raucherclub... koordinaten: N 48° 07.590' E 11° 35.682' signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Grundeinstellungen JOSM mit Windows Vista
Hallo, wie kann ich bei JOSM die Einstellungen wie bei einer Neuinstallation wieder herstellen. Habe bei Einstellungen herumgespielt und möchte nun wieder die Grundeinstellung haben. MfG dieter jasper ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Bayern
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Trautmann wrote: | Auf http://wiki.openstreetmap.org/index.php/Talk:Bavaria finden sich die | restlichen Vorschläge. Klasse Arbeit, zeigt echt so einige Leichtsinns- und Tippfehler... Ich mach mich dann mal dran ausgehend von meiner Umgebung nachzubessern. Danke, jacko. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHsKM+bCPVS12dTK4RAlYUAKCRnSaqo82LNTH2LoLVWE+bqWTjfwCcD8bd mJeF6l17ThufrCwauKAWE9k= =RWgo -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] [Fwd: [OSM-talk] RFC: Highway administrative and physical descriptions]
Für alle die nicht auf talk mitlesen, sich aber trotzdem hierfür interessieren: Original-Nachricht Betreff: [OSM-talk] [tagging] RFC: Highway administrative and physical descriptions Datum: Mon, 11 Feb 2008 17:39:31 -0600 Von: Alex Mauer [EMAIL PROTECTED] An: [EMAIL PROTECTED] Please read and comment on the proposal at http://wiki.openstreetmap.org/index.php/Proposed_features/Highway_administrative_and_physical_descriptions Thank you. -Alex Mauer hawke ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [OSM-Talk-ZA] New Garmin OSM ZA Map available.
On Feb 11, 2008 12:57 PM, Grant Slater [EMAIL PROTECTED] wrote: OSM-Talk-ZA, Updated Garmin img map file available: http://code.firefishy.com/files/garmin/osm-southafrica-080207.img How to install onto a Garmin GPS: http://wiki.openstreetmap.org/index.php/Mkgmap#Installing Alternatively to view in; Windows: http://www.geopainting.com/en/ Linux: http://qlandkarte.sourceforge.net/ / Grant Azureus Magnet Uri: magnet:?xt=urn:btih:NUVA6V7OX6QICW6DWCBT7EEJSC7USTCQ Cheers Ray -- Ray Booysen [EMAIL PROTECTED] ___ Talk-ZA mailing list Talk-ZA@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-za
Re: [Talk-cz] Znaceni turistickych cest
On Feb 11, 2008 2:13 PM, Jiri Klement [EMAIL PROTECTED] wrote: Proc..? marked_trail_red=yes marked_trail_mistni_turisticka_red=yes ;-). Aspon s tim pujde rozume pracovat v josm Pavel marked_trail_naucna_stezka_jana_pojmana=yes marked_trail_evropska_svatojakubska_cesta=yes Myslim ze pokud by se to resilo pomoci tagu, tak by mel byt pouze jeden. Tak aby renderer vedel ze jde o turistickou cestu a umel ji alespon nejak vyrenderovat. Inspirujme se znacenim cyklotras (ncn=yes, ncn_ref=42, rcn_*, lcn_*): Zakladem bude kct_. kct_green=yes kct_yellow=31415926b (cislo trasy, pro fajnsmekry) kct_green=Evropska Svatojakubska kct_red=ruin (silueta zriceniny) =peak (vyhlidka) ... kct_red=local (naucna stezka, bilocerveny trojuhelnik) To mi prijde dostatecne jednoduche a v soucasnosti pouzitelne (nezapominejte na potlatch). Jednoduchy renderer proste hleda neprazdny kct_BARVA. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] Znaceni turistickych cest
Ahoj! Je to v proposed features a nekdo tam navrhoval udelat to pomoci relace. To je asi jedina spravna cesta. Pokud se relace nejak rozumne pojmenuje Ja si nemyslim ze by to nebyla spravna cesta, a urcite neni jedina. Co je spatneho na marked_trail_red=yes ? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] Znaceni turistickych cest
Je to v proposed features a nekdo tam navrhoval udelat to pomoci relace. To je asi jedina spravna cesta. Pokud se relace nejak rozumne pojmenuje (hiking_marked_route nebo hiking_marked_path), tak je to do budoucna pouzitelne. Marked trail neni zrovna idealni, protoze trail je spis cesta ve smyslu fyzickem nez jako trajektorie. Problem je ale v renderovani. Ja treba vubec netusim, jak mapnik donutit, aby neco takoveho renderoval. IMO je relace multipolygon hard coded uvnitr a neda se s ni nic delat. Nejake rozhrani pro stylovani relaci jsem nenasel. Neni samozrejme ale problem vytahnout dane ways a renderovat to samostatne. Z meho pohledu tedy jednoznacne relace, jakozto jedina korektni cesta, jak to vyjadrit. Docasne se klidne muze pridat i znacka marked_trail a da se pomoci toho renderovat overlay s turistickym znacenim. K Jiri Klement wrote: Zdravim, Je nejaky standard pro znaceni turistickych cest? Vim ze se to uz resilo, ale myslim ze bez vysledku. Myslim ze by se melo neco rozhodnout a napsat do ceske wiki. Kdyz se to potom globalne udela jinak, tak nebude problem znaceni prevest (kdyz bude v cr jednotne) Momentalne je nejpopularnejsi marked_trail (38 vyskytu) a markedtrail (84 vyskytu). Doporucil bych jeste pridat tag marked_trail_type, kde by bylo neco jako kct_na_vyhlidku, evropska_stezka apod. Lepsi by asi bylo pouzit relace, elegatne by se tim vyresil treba problem soubehu vice tras, ale pouziti relaci neni v josm moc pohodlne. Kdyby bylo v josm mozne: - vybrat par cest, kliknout na pridat relaci, vybrat sablonu Turisticka znacka a vyplnit pozadovane informace - renderovat cesty v relaci jinym zpusobem - pri kliknuti na cestu zobrazit jeji relace tak by imho bylo pouziti relaci idealni. -- Jiri Klement ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz -- Jakub Sýkora email: [EMAIL PROTECTED] ') ICQ: 68976632 ( =- mobil: +420 777 594 201 '' ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] Znaceni turistickych cest
To asi neni uplne snadne :-(. marked_trail=red,blue marked_trail_type=kct_na_vyhlidku oops. Ja vim ze je problem se soubeznymi cestami, je to jeden z duvodu proc se na to lepe hodi relace. Co je spatneho na marked_trail_red=yes Jednak by podobnych tagu bylo celkem velke mnozstvi a pak to porad neni univerzalni reseni. Existuji mista, kde napriklad jde vedle sebe turisticka znacka a mistni turisticka znacka stejne barvy. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] Znaceni turistickych cest
Ahoj! To asi neni uplne snadne :-(. marked_trail=red,blue marked_trail_type=kct_na_vyhlidku oops. Ja vim ze je problem se soubeznymi cestami, je to jeden z duvodu proc se na to lepe hodi relace. Co je spatneho na marked_trail_red=yes Jednak by podobnych tagu bylo celkem velke mnozstvi a pak to porad neni univerzalni reseni. Existuji mista, kde napriklad jde vedle sebe turisticka znacka a mistni turisticka znacka stejne barvy. Proc..? marked_trail_red=yes marked_trail_mistni_turisticka_red=yes ;-). Aspon s tim pujde rozume pracovat v josm Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] Znaceni turistickych cest
Dival jsem se na zdrojaky osm2pgsql a vypada to, ze multipolygon je opravdu hard-coded, jine typy relaci se uplne ignoruji. Jednoduchym docasnym resenim by bylo pred vykreslenim doplnit do vsech way v relaci nejaky tag, napriklad marked_route_blue, ktery by se pak dal snadno nastylovat. Porad ale zustava neprijemne pouzivani relaci v josm. Pokud vim, tak neni mozne nastylovat cestu podle relaci do kterych patri. Navic ani po vyberu cesty se neukaze seznam jeji relaci. On 2/11/08, Jakub Sykora [EMAIL PROTECTED] wrote: Je to v proposed features a nekdo tam navrhoval udelat to pomoci relace. To je asi jedina spravna cesta. Pokud se relace nejak rozumne pojmenuje (hiking_marked_route nebo hiking_marked_path), tak je to do budoucna pouzitelne. Marked trail neni zrovna idealni, protoze trail je spis cesta ve smyslu fyzickem nez jako trajektorie. Problem je ale v renderovani. Ja treba vubec netusim, jak mapnik donutit, aby neco takoveho renderoval. IMO je relace multipolygon hard coded uvnitr a neda se s ni nic delat. Nejake rozhrani pro stylovani relaci jsem nenasel. Neni samozrejme ale problem vytahnout dane ways a renderovat to samostatne. Z meho pohledu tedy jednoznacne relace, jakozto jedina korektni cesta, jak to vyjadrit. Docasne se klidne muze pridat i znacka marked_trail a da se pomoci toho renderovat overlay s turistickym znacenim. K Jiri Klement wrote: Zdravim, Je nejaky standard pro znaceni turistickych cest? Vim ze se to uz resilo, ale myslim ze bez vysledku. Myslim ze by se melo neco rozhodnout a napsat do ceske wiki. Kdyz se to potom globalne udela jinak, tak nebude problem znaceni prevest (kdyz bude v cr jednotne) Momentalne je nejpopularnejsi marked_trail (38 vyskytu) a markedtrail (84 vyskytu). Doporucil bych jeste pridat tag marked_trail_type, kde by bylo neco jako kct_na_vyhlidku, evropska_stezka apod. Lepsi by asi bylo pouzit relace, elegatne by se tim vyresil treba problem soubehu vice tras, ale pouziti relaci neni v josm moc pohodlne. Kdyby bylo v josm mozne: - vybrat par cest, kliknout na pridat relaci, vybrat sablonu Turisticka znacka a vyplnit pozadovane informace - renderovat cesty v relaci jinym zpusobem - pri kliknuti na cestu zobrazit jeji relace tak by imho bylo pouziti relaci idealni. -- Jiri Klement ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz -- Jakub Sýkora email: [EMAIL PROTECTED] ') ICQ: 68976632 ( =- mobil: +420 777 594 201 '' ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [OSM-talk-fr] limites région/département
serge karamazov a écrit : Je dirais plutôt que personne n'a encore pu apporter la preuve qu'il était utilisable pour OSM. Renaud. Question intéressante de droit : est-ce au plaignant de prouver qu'il y a violation d'une licence ou à l'accusé de démontrer qu'il n'a pas causé de préjudice ? Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] limites région/département
Pieren Pieren a écrit : L'IGN fournit des cartes des départements français libres de droits c'est ici : http://www.ign.fr/rubrique.asp?rbr_id=441 Libres de droit.. sauf pour une utilisation commerciales. Hors, la license OSM n'interdit pas une utilisation commerciale de ses données. Il est donc impossible d'utiliser des données qui nécessitent une autorisation préalable, ce qui est le cas de toutes les données de l'IGN (dans un cadre commercial). Oui. Mais l'impossibilité d'utiliser les données ne vient pas de là ! Elle réside dans le fait que ce sont des images mortes (cad sans repères, sans échelle, sans orientation, etc.). Autant faire directement une limite départementale sur les images Landsat (en jetant un oeil sur les cartes des départements de l'encyclopédie Larousse du XIXe siècle (disponible sur Gallica), ce sera plus précis (et complètement libre de droits ;-) Quant au fait que des données soient dans wikimedia, cela ne garantie pas l'absence de droits sur les données. Wikimedia/pedia utilisent leur droit de citation, d'ailleurs d'une façon parfois limite. Par contre Wikipedia n'autorise pas une réutilisation commerciale de ses données. C'est peut-etre là la principale différence avec la license d'OSM. Problème intéressant. Pour en revenir au cadastre, on est là - je pense - dans un tout autre domaine qui n'est pas sous la férule de l'IGN. On est là dans des documents administratifs faisant partie - à mon avis - du domaine public. Pieren Pour en avoir discuté avec un juriste, il semble qu'il (la méthodologie exposée ces dernières jours) y ait création de données nouvelles, non préjudice, information consultable de visu (donnée publique), etc. Il est intéressant de noter que les données du cadastre.gouv.fr ne sont la plupart du temps pas géoréférencées et surtout non contigües. D'où la BD parcellaire de l'IGN qui a la mission (composante du RGE) de dresser un continuum de la propriété foncière, à partir des données issues de la DGI. A noter également que la digitalisation (c'est-à-dire convertir un image en objet vectoriel) des plans cadastraux est l'oeuvre des collectivités locales (communes, communautés de communes -du moins en Alsace). Cela prouve bien qu'une feuille achetée à la DGI du coin peut servir, sans restriction, à de la création de données nouvelles dont la propriété intellectuelle revient à la personne morale ou physique qui a consenti un investissement substantiel (il me semble que ce sont les termes exacts de la loi sur le droit des bases de données) pour sa constitution. Le conventionnement entre la DGI et les collectivités est un histoire assez complexe qui a bien évolué dans le temps notamment sur la propriété des nouvelles données créées à partir du plan cadastral. Si une commune ou un groupement de communes peut faire cela, pourquoi un contribuable ne pourrait-il pas le faire (d'autant plus qu'il a déjà payé via son impôt les moyens mis en oeuvre par lesdites collectivités pour assurer une mission de service public) ? Le fait que le service du cadastre propose ses feuilles sous forme numérisée (une impression papier payante ou un fichier pdf) importe peu ; l'effort pour réassembler les objets qui nous intéressent est plus que conséquent. Pour tracer une route, disons de 5 points, il peut être nécessaire de réorienter 3 ou 4 feuilles, de les géoréférencer, de digitaliser ou d'interpréter les données de base. Pour, au final, avoir une information qui a un autre sens que celles sur lesquelles elles s'appuient et que l'Etat a obligation de porter à connaissance. Les restrictions légitimes imposées par la DGI concernent l'utilisation du plan cadastral en tant que tel : pas d'utilisation commerciale (c'est une source de revenu pour l'Etat). De là à en déduire qu'on ne peut en aucun cas toucher à ni exploiter de l'information rendue publique (de peur d'être contaminé par de la donnée copyrightée), c'est croire qu'une administration ou une entreprise peut posséder tous les droits sur la description d'un territoire. Ce n'est heureusement pas (encore) légal. Ce n'est pas parce que Microsoft détient 90 % du marché de l'ordinateur personnel, que cela lui confère le droit d'imposer légalement l'obligation d'acheter le dernier avatar de son système d'exploitation avec tout nouvelle machine. Cela relève du choix (et donc de la liberté) de l'utilisateur. Enfin, disons c'est mon avis d'administrateur de données géographiques d'une collectivité locale (qui m'engage que moi d'ailleurs). cordialement, Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] limites région/département
Alban a écrit : La BD France de Cartographes Associés. Cette BD représente le découpage des départements Français et a le mérite d'^tre bcp plus précise que GeoFla dont l'échelle de reférence est proche du 1/10 cf. l'apperçu http://wiki.openstreetmap.org/index.php/User:Alban ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
