Re: [OSM-talk] Zonal restrictions.
On Wed, 13 May 2009 15:54:36 +0100, Dave Stubbs osm.l...@randomjunk.co.uk wrote: The first thing I thought of when reading this is, to use a relation. 'Relations are not categories' applies to people making relations out of all hotels or All hotels in London, doesn't really apply here. type=zone name=Dublin Centre maxspeed=20kph parking=no Where zone is a known geographic area? A bounding way with tags like: zone = restriction maxspeed = 20kph parking = no seems like the best way to do it to me if you don't want to just replicate the tags on everything (and I can understand why you wouldn't want to do that). There's no software that'll pay attention to it atm, but then it's not long ago that everything ignored route relations too. I really wouldn't recommend relations for specifying what things are inside an area. It's a waste of two entire dimensions our dataset happens to have. I completely agree here. A polygon is a simpler, easier to evaluate, to tag and much, much less error-prone way to do this compared to a relation that has all ways in that area as members. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
On Wed, 13 May 2009 17:08:51 +0200, Ben Laenen benlae...@gmail.com wrote: I really wouldn't recommend relations for specifying what things are inside an area. It's a waste of two entire dimensions our dataset happens to have. So while it may work for many zonal restrictions to use an area (although even then there are still issues) you need another way as well due to the bridge/tunnel issue, and that other mehod can only be relations. Sorry to say that but if there are ways within the zone such as bridges and tunnels that are not affected, then this is not a zonal restriction at all. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
marcus.wolsc...@googlemail.com wrote: Sorry to say that but if there are ways within the zone such as bridges and tunnels that are not affected, then this is not a zonal restriction at all. That's ridiculous. It's very possible for a bridge/tunnel to *cross* a zone, while not being part of the zone itself. E.g. an elevated motorway going over some ground-level zone, just isn't part of that zone. Even if that bridged/tunneled road had an exit into the zone, zonal regulations would only start (or end, for that matter) at that point. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Corine Land Cover becomes a potential OSM data source...
Pieren, A new OSMF Working Group is being formed to support groups and individuals with the import of new public and private data. I've copied SteveC who will be leading the group so that your email reaches the new groups radar. Cheers Andy -Original Message- From: talk-boun...@openstreetmap.org [mailto:talk- boun...@openstreetmap.org] On Behalf Of Pieren Sent: 13 May 2009 10:13 PM To: OSM Subject: [OSM-talk] Corine Land Cover becomes a potential OSM data source... at least in France. The Corine Land Cover (CLC) is refering to a european programme establishing a computerised inventory on land cover of the 27 EC member states and other European countries, at an original scale of 1: 100 000, using 44 classes of the 3-level Corine nomenclature. It is produced by the European Environment Agency (EEA) and its member countries and is based on the results of IMAGE2000, a satellite imaging programme undertaken jointly by the Joint Research Centre of the European Commision and the EEA . Until now, the terms of use did not allow commercial use unless the Agency has expressly granted the right to do so. This was stopping any possibility to use the land use data for OSM. But, beginning of 2009, french environment agency (IFEN) released the new version of the dataset of year 2006, called CLC2006 with a newer version of the terms of use which explicitely allow commercial use. After some discussions with the french authorities responsible for the programme in France, it has been clearly stated that the CLC2006 data for France can be imported into OSM. During this discussion, it appeared that the same way of opening the data access has been mentionned at the EEA committee. The ad hoc committee in Q1/2009 suggested the following proposal for the new terms of use: Use rights : EEA is promoting the widest possible use of all data produced during the project. All core land cover data (national and European CLC 2000-2006 changes, national and European CLC2006 and related metadata, high resolution built-up areas, including degree of soil sealing, 2006 and high resolution forest areas, 2006) will be made available free of charge via the web, for non-commercial as well as commercial uses. But until it is released at EEA level, only specific national programmes who officially adopted new terms of use compatible with the OSM licence could take this data as a potential source. For France, we are now looking how we will be able to import some of 44 classes. We also created a wiki page trying to translate the CLC nomenclature to OSM tags: http://wiki.openstreetmap.org/wiki/Corine_Land_Cover I would like to see your comments about this translation table but also more in general, about this data source. It is possible that some other states already used CLC data for OSM, in which case, we would appreciate if they could share their experience. regards, Pieren EEA web site for CLC2006: http://etc-lusi.eionet.europa.eu/CLC2006/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Corine Land Cover becomes a potential OSM data source...
On Thu, May 14, 2009 at 11:05 AM, Andy Robinson (blackadder-lists) ajrli...@googlemail.com wrote: Pieren, A new OSMF Working Group is being formed to support groups and individuals with the import of new public and private data. I've copied SteveC who will be leading the group so that your email reaches the new groups radar. Cheers Andy Thanks for your reply. I think we are exactly in this case. Once we agree which layers will be imported and the tag mapping, we can easily convert the data to osm format. But we are facing the problem of how to detect and resolve the conflicts with existing landuse data in OSM which are usually (but not always) more accurate (Yahoo imagery or french cadastre). I know we are not the first country having this problem and we would like to know how it was solved with other mass imports. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Corine Land Cover becomes a potential OSM data source...
Hi Pieren wrote: But we are facing the problem of how to detect and resolve the conflicts with existing landuse data in OSM which are usually (but not always) more accurate (Yahoo imagery or french cadastre). I know we are not the first country having this problem and we would like to know how it was solved with other mass imports. We are currently importing public transport information for the UK (NaPTAN) and are having a similar problem with existing data in OSM. Our approach is to tag the imported data specially so that it can easily be found in the database but does not show up on the map (i.e. all imported bus stops are tagged with source=naptan_import but do not have highway=bus_stop tag). Mappers can then check the imported data and activate bus stops by adding a highway=bus_stop tag to it or copy the imported tags over to an existing OSM bus stop. To aid this task a web-based tool is being developed at the moment. The tool displays all bus stops from OSM and all newly imported stops on a map and can find pairs of similar bus stops in the existing and the new dataset (based on proximity and similar names). The user can then easily select pairs and merge them. Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
marcus.wolsc...@googlemail.com wrote: I completely agree here. A polygon is a simpler, easier to evaluate, to tag and much, much less error-prone way to do this compared to a relation that has all ways in that area as members. Inclusion tests (especially if even a way segment can be intersected by the area polygon) are easier for evaluation than direct membership references? I doubt that this is usually correct. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
On Thursday 14 May 2009, MP wrote: Except it's not a geographic area, but rather a set of streets with that restriction. If a bridge or tunnel without the restriction goes over/under a street with the restriction you'll have a problem. In that case, that bridge can have differen speed limits set directly on the way. Just define that tags on individual ways override tags set in the zone and this will solve the issue. So while it may work for many zonal restrictions to use an area (although even then there are still issues) you need another way as well due to the bridge/tunnel issue, and that other mehod can only be relations. I've seen many zones with some limitations (mostly speed limit or some parking limitations), but such zones rarely contain any bridges or tunnels. If they do, they can be either tagged individually, or we can also make new relation that will contain the zone and roads that are NOT in the zone (relation containing those few exceptions like the bridges, tunnels, etc ... so they won't need individual tagging) And who's going to think about that? You're not exactly making it easy for a mapper if he or she has to know about features you're not able to see on the road he has just explored... I'd suggest one should tag a road with features found on that road and not with features that are missing on the road. And these situations are more common than you may think. Built-up areas are the most common where such a thing happens here as they're of course the largest kind of zonal restrictions, and each city will have it's roads crossing them without being part of it. But I've also seen it with zones with parking restrictions or zones with speed restrictions. And you just can't tag the road with for example an overruling maxspeed tag, as the road may just have its default maxspeed in which case you don't tag that speed. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Corine Land Cover becomes a potential OSM data source...
Interesting. We will be having the same kind of import versus existing data issue once more (if and) when the Nationaal Wegenbestand (National road database) is made available by the transport ministry. I did not give it much thought yet - may be some of my Dutch co-OSM-ers will have a more elaborate train of thought - but I was thinking along similar lines: import the data but tag it so that it won't show up in the map. Have a dedicated map layer on a local server that can be used to check existing user data, may be even a Potlatch layer if at all possible. I guess JOSM support would be easy enough through the WMS plugin. Other noteworthy fact is that we have had this issue before, in 2007 when importing the AND data. There was much discussion then on how to approach, and as far as I can remember we had an opt-out system then: if you don't want your current user data overwritten by AND data, you could indicate such and this way some particularly well mapped areas were untouched by the AND data. But back then, the Netherlands had only isolated pockets of good OSM coverage. martijn van exel -+- mve...@gmail.com -+- http://www.schaaltreinen.nl/ On Thu, May 14, 2009 at 12:23, Christoph Boehme christ...@b3e.net wrote: Hi Pieren wrote: But we are facing the problem of how to detect and resolve the conflicts with existing landuse data in OSM which are usually (but not always) more accurate (Yahoo imagery or french cadastre). I know we are not the first country having this problem and we would like to know how it was solved with other mass imports. We are currently importing public transport information for the UK (NaPTAN) and are having a similar problem with existing data in OSM. Our approach is to tag the imported data specially so that it can easily be found in the database but does not show up on the map (i.e. all imported bus stops are tagged with source=naptan_import but do not have highway=bus_stop tag). Mappers can then check the imported data and activate bus stops by adding a highway=bus_stop tag to it or copy the imported tags over to an existing OSM bus stop. To aid this task a web-based tool is being developed at the moment. The tool displays all bus stops from OSM and all newly imported stops on a map and can find pairs of similar bus stops in the existing and the new dataset (based on proximity and similar names). The user can then easily select pairs and merge them. Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] R: RFC: amenity=mortuary (and amenity=emergency_room)
On Wed, May 13, 2009 at 8:39 PM, David Paleino d.pale...@gmail.com wrote: On Wed, 13 May 2009 18:16:59 +0200, Fabrizio Carrai wrote: I agree for the morgue term. Well, ok. I'm not particularly in favour of one version over the other ;) I would say something to key amenity an why I would prefer the use of the key landuse Well, landuse?!.. it's not land, it usually is a building... Maybe I'm missing this, but maybe you forgot your motivations for landuse? I don't know in other launguages but in italian the most common meaning for AMENITY is something nice, beautiful, pleasant... Eh già ;) However, I'd really stick to amenity: those are meant as facilities (maybe facility= would be better? But then we would need to change a *lot* of tags out there) eh, so somebody would need to write some update rules for a bot to change them. I don't see the problem with regards to mass edits such as what would be required here. It makes far more sense to use a sensible tag name that can best describe what is required/being tagged. k. -- http://openstreetmap.org/user/kenguest ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
On 14 May 2009, at 11:55, Ben Laenen wrote: On Thursday 14 May 2009, MP wrote: [..] And these situations are more common than you may think. Built-up areas are the most common where such a thing happens here as they're of course the largest kind of zonal restrictions, and each city will have it's roads crossing them without being part of it. But I've also seen it with zones with parking restrictions or zones with speed restrictions. And you just can't tag the road with for example an overruling maxspeed tag, as the road may just have its default maxspeed in which case you don't tag that speed. Yeah but the default maxspeed becomes the one of the zone. So the road would then need a specific restriction, or the zone would need to be split. The following evaluation hierarchy could be used: 1. Use the default restrictions for that type of road. 2. Is a road in a restriction zone? Use those restrictions instead of in 1. 3. Does the road have a specific restriction on it? USe that instead of 1. and/or 2. Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Corine Land Cover becomes a potential OSM data source...
Hi, Martijn van Exel wrote: Interesting. We will be having the same kind of import versus existing data issue once more (if and) when the Nationaal Wegenbestand (National road database) is made available by the transport ministry. I did not give it much thought yet - may be some of my Dutch co-OSM-ers will have a more elaborate train of thought - but I was thinking along similar lines: import the data but tag it so that it won't show up in the map. Have a dedicated map layer on a local server that can be used to check existing user data, may be even a Potlatch layer if at all possible. I guess JOSM support would be easy enough through the WMS plugin. This way (import everything with funny tagging and let users then work with it) is, in my eyes, suitable if you have reason to believe that a lot of what you import is actually going to be used. If, on the other hand, it is likely that 80% of what you import will later be deleted because it was there already, then it may be better to run the import like we did the Nordrhein-Westfalen import: Set up a completely separate WMS layer that can be shown in the backgroundd and allow people to import individual objects where they think it's worthwile. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Corine Land Cover becomes a potential OSM data source...
Thanks for your suggestions. In our case, it is more about 80% of the import dataset that will stay. And we speak about e.g. forests, tree plantations, agricultural areas,etc which is a huge surface in France. Tha't why our preference would go to some solution making the import as much as possible automatic. For instance, a tool detecting conflicts between the new landuse polygones and existing landuse polygones, then splitting the data in two sets, one without conflicts which could be directly uploaded and one with conflicts which would require some individual investigation/edits. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Corine Land Cover becomes a potential OSM data source...
On 14/05/09 11:23, Christoph Boehme wrote: We are currently importing public transport information for the UK (NaPTAN) and are having a similar problem with existing data in OSM. Our approach is to tag the imported data specially so that it can easily be found in the database but does not show up on the map (i.e. all imported bus stops are tagged with source=naptan_import but do not have highway=bus_stop tag). Mappers can then check the imported data and activate bus stops by adding a highway=bus_stop tag to it or copy the imported tags over to an existing OSM bus stop. Has consideration been given in any future API/database schema updates of having support for layers, like e.g. the GIMP does it for graphics? So you could import data into a new layer with all the appropriate tags and then merge down as appropriate. The slippy map would only show the base layer. This sort of support might also be useful for people reusing OSM software and schemas who want to overlay their own data onto the OSM data. Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] QA with a lawyer
On 13/05/09 14:23, Frederik Ramm wrote: Sounds like: We have a honest desire to sue the shit out of you if you violate any of our 52 random rules but we will grudgingly refrain from doing so if laws in your jurisdiction should have the nerve of being against us. ;-) That's only if the rest of the licence sounds like We have a honest desire to sue the shit out of you if you violate any of our 52 random rules. And if you think that, then your problem would not be with the fair use clause. Gerv ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Corine Land Cover becomes a potential OSM data source...
Martijn van Exel wrote: Interesting. We will be having the same kind of import versus existing data issue once more (if and) when the Nationaal Wegenbestand (National road database) is made available by the transport ministry. I did not give it much thought yet - may be some of my Dutch co-OSM-ers will have a more elaborate train of thought - but I was thinking along similar lines: import the data but tag it so that it won't show up in the map. Have a dedicated map layer on a local server that can be used to check existing user data, may be even a Potlatch layer if at all possible. I guess JOSM support would be easy enough through the WMS plugin. I have to agree with Frederik on this. With the NWB you mention, it's likely the vast majority of it will not be relevant to NL coverage, since we already have had a mass import of AND data. Why should we 'pollute' the OSM db with data that's not going to be used on a large scale. I'd too rather see such a source of data on a separate layer/db, through WMS for instance, so that we can compare, and (like Gervase puts it) merge down what we want. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Corine Land Cover becomes a potential OSM data source...
On Thu, May 14, 2009 at 16:52, Lennard l...@xs4all.nl wrote: Martijn van Exel wrote: Interesting. We will be having the same kind of import versus existing data issue once more (if and) when the Nationaal Wegenbestand (National road database) is made available by the transport ministry. I did not give it much thought yet - may be some of my Dutch co-OSM-ers will have a more elaborate train of thought - but I was thinking along similar lines: import the data but tag it so that it won't show up in the map. Have a dedicated map layer on a local server that can be used to check existing user data, may be even a Potlatch layer if at all possible. I guess JOSM support would be easy enough through the WMS plugin. I have to agree with Frederik on this. With the NWB you mention, it's likely the vast majority of it will not be relevant to NL coverage, since we already have had a mass import of AND data. Why should we 'pollute' the OSM db with data that's not going to be used on a large scale. I disagree with you on relevance. The NWB data is likely to be more current and much more detailed than the AND data, so much of it will be relevant and usable - although not directly. While the level of detail would make for a massive import, setting up a NWB WMS layer to be used in JOSM would probably be a better idea than to import the entire NWB into the OSM db. I don't know what kind of layer Potlatch would be able to handle, but we could probably try and provide a yahoo-compatible tile layer on top of the WMS. T o be discussed on talk-nl - we're getting OT here ;) I'd too rather see such a source of data on a separate layer/db, through WMS for instance, so that we can compare, and (like Gervase puts it) merge down what we want. Yes - I'm with you there, although we should take a close look at NWB to see if there's some direct import possibilities. I'm thinking for example cycle paths along roads, but I don't want to get ahead of things here. -- Martijn ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Data Import Support Working Group
On Wed, May 13, 2009 at 1:26 AM, SteveC st...@asklater.com wrote: The foundation today discussed the perceived need for a working group to help people import data. We know there are highly talented individuals out there who are able to find data to import, have the social skills and time to get data holders to release it to OSM, have the legal knowledge to see if it's ok to import and have the technical skills to do the actual importing. They are doing amazing work. However there are those that can do only a portion of this. Thus we would like to help the people finding the data meet the people who can import it, and them feel they have backing. We are not looking to stomp on existing imports. We wish to help with the large number of datasets out there without a champion who has all the skills needed to get it imported. There is a lot of data out there! We will prioritise it and help get it imported. So, are you someone who knows about some datasets? Are you able to do the importing? Do you have a little time each week to help guide the process and talk to people who might have data? Then please get in touch to help start this group. We will meet approximately every week or two for an hour long phone call. This is a very welcome development, I for one have acquired a dataset on behalf of OSM which is waiting for someone to write the required code to import it and keep it up to date[1]. I would be interested in being part of this group, e.g. by helping collate and classify datasets that are waiting to be imported, and even by writing code required to do the importing. But can this please be coordinated in a more globally/non-English speaking/non-GMT friendly forum than a weekly telephone conference? You obviously seem to have a strong preference for phone conferences but judging from the responses to the (proposed?) ODbL teleconference a lot of people who'd otherwise be willing to take part in that (and presumably this) effort find that an inconvenient forum. 1. http://wiki.openstreetmap.org/wiki/Iceland_postal_code_database ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Data Import Support Working Group
On May 14, 2009, at 11:26 AM, Ævar Arnfjörð Bjarmason wrote: This is a very welcome development, I for one have acquired a dataset on behalf of OSM which is waiting for someone to write the required code to import it and keep it up to date[1]. Doing the import is straightforward. Keeping it up to date is trickier. I would be interested in being part of this group, e.g. by helping collate and classify datasets that are waiting to be imported, and even by writing code required to do the importing. Me too. But can this please be coordinated in a more globally/non-English speaking/non-GMT friendly forum than a weekly telephone conference? Two things: o There's a big hole in the Pacific into which we can throw the night-time on the schedule. Pushes on the edges with Japan and Hawaii, and the very eastern parts of Russia and western parts of Alaska, but we're programmers. We're used to not sleeping, right? o And in a similar vein, except for China, English is the language of computer programmers. o Phone calls are a very effective way to keep a group in synch and on time. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Data Import Support Working Group
2009/5/13 SteveC st...@asklater.com: All The foundation today discussed the perceived need for a working group to help people import data. We know there are highly talented individuals out there who are able to find data to import, have the social skills and time to get data holders to release it to OSM, have the legal knowledge to see if it's ok to import and have the technical skills to do the actual importing. They are doing amazing work. However there are those that can do only a portion of this. Thus we would like to help the people finding the data meet the people who can import it, and them feel they have backing. We are not looking to stomp on existing imports. We wish to help with the large number of datasets out there without a champion who has all the skills needed to get it imported. There is a lot of data out there! We will prioritise it and help get it imported. So, are you someone who knows about some datasets? Are you able to do the importing? Do you have a little time each week to help guide the process and talk to people who might have data? Then please get in touch to help start this group. We will meet approximately every week or two for an hour long phone call. Best Steve Being the (somewhat delegated) person who is currently doing the import of the NaPTAN data, I suppose I have an interest in this group, but demands on my time are currently very high, so its unlikely I'll be of any help in the near future. -- Regards, Thomas Wood (Edgemaster) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Data Import Support Working Group
On Thu, 14 May 2009 15:26:37 +, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: On Wed, May 13, 2009 at 1:26 AM, SteveC st...@asklater.com wrote: The foundation today discussed the perceived need for a working group to help people import data. We know there are highly talented individuals out there who are able to find data to import, have the social skills and time to get data holders to release it to OSM, have the legal knowledge to see if it's ok to import and have the technical skills to do the actual importing. They are doing amazing work. I also welcome this development. I could need support in organizing the Import of the german TMC location-codes myself. (This will allow routing- and navigation -applications that use OSM to use electronic traffic-messages very easily.) I already wrote the code to parse these location-codes, have a schema, reference-implementation to use them, ... but I don't know how to organize the import of the parts that can be automatically imported and more importantly the parts that need manual assistance. (When germany is done there are a dozen other countries with TMC location-codes that have published them openly or may be willing to do so.) Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] [OSM-talk] Corine Land Cover becomes a potential OSM data source...
On Thu, May 14, 2009 at 16:52, Lennard l...@xs4all.nl wrote: Martijn van Exel wrote: Interesting. We will be having the same kind of import versus existing data issue once more (if and) when the Nationaal Wegenbestand (National road database) is made available by the transport ministry. I did not give it much thought yet - may be some of my Dutch co-OSM-ers will have a more elaborate train of thought - but I was thinking along similar lines: import the data but tag it so that it won't show up in the map. Have a dedicated map layer on a local server that can be used to check existing user data, may be even a Potlatch layer if at all possible. I guess JOSM support would be easy enough through the WMS plugin. I have to agree with Frederik on this. With the NWB you mention, it's likely the vast majority of it will not be relevant to NL coverage, since we already have had a mass import of AND data. Why should we 'pollute' the OSM db with data that's not going to be used on a large scale. I disagree with you on relevance. The NWB data is likely to be more current and much more detailed than the AND data, so much of it will be relevant and usable - although not directly. While the level of detail would make for a massive import, setting up a NWB WMS layer to be used in JOSM would probably be a better idea than to import the entire NWB into the OSM db. I don't know what kind of layer Potlatch would be able to handle, but we could probably try and provide a yahoo-compatible tile layer on top of the WMS. T o be discussed on talk-nl - we're getting OT here ;) I'd too rather see such a source of data on a separate layer/db, through WMS for instance, so that we can compare, and (like Gervase puts it) merge down what we want. Yes - I'm with you there, although we should take a close look at NWB to see if there's some direct import possibilities. I'm thinking for example cycle paths along roads, but I don't want to get ahead of things here. -- Martijn ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-talk] Corine Land Cover becomes a potential OSM data source...
Martijn van Exel wrote: I disagree with you on relevance. The NWB data is likely to be more current and much more detailed than the AND data, so much of it will be relevant and usable - although not directly. Onzin :) Van iemand enorm dicht bij de bron: Verwacht trouwens niet te veel van het NWB zelf. Openstreetmap heeft nu al een betere kwaliteit dan het NWB en dat verschil zal alleen maar toenemen. Maar het NWB is wel de sleutel tot een heleboel overheidsdata en daarom is een koppeling NWB-openstreetmap meer dan wenselijk. Met als bijeffect dat je dan dus fouten in beide bestanden op kunt sporen. While the level of detail would make for a massive import, setting up a NWB WMS layer to be used in JOSM would probably be a better idea than to import the entire NWB into the OSM db. OSM zal eerst eens wat read only lagen moeten introduceren. Om zo scheiding van data te bewerkstelligen en daarvanaf branches te kunnen maken. Dan winnen er meer partijen... overheid en OSM. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Planet BeNeLux
Zoals je al weet worden ze meegenomen in de dagelijkse update! Maar ik wou het toch nog even aan de rest van talk laten weten. zie http://planet.openstreetmap.nl --Roeland On Tuesday 12 May 2009 01:17:40 Milo van der Linden wrote: Fantastisch! Als je me kunt vertellen hoe ik zo'n poly bestand in elkaar zet, is het dan misschien een idee om ook alvast poly's te gaan maken voor aruba, curacao, bonaire, st-maarten, st-eustacius en de rest van het caribisch gebied? Groet, Milo Roeland Douma wrote: Goede avond! De nieuwe tile server schiet al aardig op. En als nieuwe feature draaien we nu in plaats van planet-nl planet-benelux. Er is een mooie polygoon gemaakt om de benelux heen waardoor deze kleiner is dan planet-nl. Maar het is natuurlijk vooral handig dat nu de hele benelux een snelle tile server krijgt waardoor hopelijk nog meer gemapt kan worden! Elke nacht wordt er een nieuwe planet-benelux gemaakt welke uiteraard beschikbaar is voor een ieder die hier iets mee wil doen. Zie http://planet.openstreet.nl Vanaf nu zullen er iets vaker berichten volgen over de nieuwe tile server, welke hopelijk snel de oude kan vervangen! Groet, --Roeland ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[talk-au] Photographers face wider anti terror curbs news
http://www.amateurphotographer.co.uk/news/Photographers_face_wider_anti_terror_curbs_news_281398.html From a UK site, where they are reporting on training civilians to keep a watch on 'hostile reconnaissance'. This urges people to look out for 'overt/covert photography' as well as those in possession of 'photographs, maps, global positioning systems, photographic equipment, (cameras, zoom lenses, camcorders)'. I can see a magnificent waste of time as OSM mappers are reported on across the UK, and real terrorists are missed. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] tlw. erledigt....
Jan Tappenbeck schrieb:
Moin !
da war der Upload etwas langsamer als die Anfrage !
Jetzt werden zwar alle dargestellt - aber mit den Links klemmpt das noch
immer !
Aber auch hierzu würde ich mich freuen, wenn man mir noch einen tipp
geben könnte.
Gruß Jan :-)
Jan Tappenbeck schrieb:
Moin !
ich bastel gerade an einer Karte in der Arch. Denkmäler dargestellt
werden sollen. Für Schleswig-Holstein habe ich 93 Stück exportiert und
in einer Datei hinterlegt.
Es werden aber leider nicht alle in der Karte dargestellt. Auch
funktioniert das mit dem Anzeigen der PopUp-Menüs nicht.
Vermutlich bricht das Programm irgendwo ab - hat einer eine Idee wie man
diesem Fehler auf die Schliche kommen kann.
Die Seite findet sich unter
http://www.tappenbeck.net/osm/deu/archaeologie.php und die Daten unter
http://www.tappenbeck.net/osm/data/osm_archaeologie.txt
Kann mir einer von Euch mit einem tollen Tipp weiterhelfen?
Gruß Jan :-)
Moin,
m. W. muss der anklickbare Icon-Layer als allerletztes zur Karte
hinzugefügt werden, sonst sind die Icons nicht anklickbar.
Du fügst aber hinterher noch (ein weiteres Mal) das
LayerSwitcher-Control hinzu, obwohl es bereits am Anfang in den Controls
enthalten ist,
siehe Quelltext:
map = new OpenLayers.Map('map',
{ maxExtent: new
OpenLayers.Bounds(-20037508.34,-20037508.34,20037508.34,20037508.34),
numZoomLevels: 20,
maxResolution: 156543.0399,
units: 'm',
projection: new OpenLayers.Projection(EPSG:900913),
displayProjection: new OpenLayers.Projection(EPSG:4326),
controls:[
new OpenLayers.Control.Permalink(),
new OpenLayers.Control.MouseDefaults(),
new OpenLayers.Control.LayerSwitcher(),
new OpenLayers.Control.MousePosition(),
new OpenLayers.Control.PanZoomBar()
]
});
[...]
map.addLayer(pois);
map.addControl(new OpenLayers.Control.LayerSwitcher());
Ich habe es jetzt nicht getestet, aber evtl. liegt es daran.
Gruß
Georg
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tlw. erledigt....
hi !
das war leider nicht die ursache !
gruß Jan :-)
Georg Feddern schrieb:
Jan Tappenbeck schrieb:
Moin !
da war der Upload etwas langsamer als die Anfrage !
Jetzt werden zwar alle dargestellt - aber mit den Links klemmpt das noch
immer !
Aber auch hierzu würde ich mich freuen, wenn man mir noch einen tipp
geben könnte.
Gruß Jan :-)
Jan Tappenbeck schrieb:
Moin !
ich bastel gerade an einer Karte in der Arch. Denkmäler dargestellt
werden sollen. Für Schleswig-Holstein habe ich 93 Stück exportiert und
in einer Datei hinterlegt.
Es werden aber leider nicht alle in der Karte dargestellt. Auch
funktioniert das mit dem Anzeigen der PopUp-Menüs nicht.
Vermutlich bricht das Programm irgendwo ab - hat einer eine Idee wie man
diesem Fehler auf die Schliche kommen kann.
Die Seite findet sich unter
http://www.tappenbeck.net/osm/deu/archaeologie.php und die Daten unter
http://www.tappenbeck.net/osm/data/osm_archaeologie.txt
Kann mir einer von Euch mit einem tollen Tipp weiterhelfen?
Gruß Jan :-)
Moin,
m. W. muss der anklickbare Icon-Layer als allerletztes zur Karte
hinzugefügt werden, sonst sind die Icons nicht anklickbar.
Du fügst aber hinterher noch (ein weiteres Mal) das
LayerSwitcher-Control hinzu, obwohl es bereits am Anfang in den Controls
enthalten ist,
siehe Quelltext:
map = new OpenLayers.Map('map',
{ maxExtent: new
OpenLayers.Bounds(-20037508.34,-20037508.34,20037508.34,20037508.34),
numZoomLevels: 20,
maxResolution: 156543.0399,
units: 'm',
projection: new OpenLayers.Projection(EPSG:900913),
displayProjection: new
OpenLayers.Projection(EPSG:4326),
controls:[
new OpenLayers.Control.Permalink(),
new OpenLayers.Control.MouseDefaults(),
new OpenLayers.Control.LayerSwitcher(),
new OpenLayers.Control.MousePosition(),
new OpenLayers.Control.PanZoomBar()
]
});
[...]
map.addLayer(pois);
map.addControl(new OpenLayers.Control.LayerSwitcher());
Ich habe es jetzt nicht getestet, aber evtl. liegt es daran.
Gruß
Georg
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bezeichnung von Landes-/Staatsstraßen
Jürgen Frank schrieb: Mir ist schon öfter aufgefallen, dass in manchen routingfähigen OSM- Karten für Garmin-Geräte bzw. Straßenklassifizierungen, sofern diese keine Nummer haben (ref-Tag IIRC) als Staatsstraßen bezeichnet werden. Das ist für alle User, die nicht in einem Freistaat, sondern einem normalen Bundesland wohnen, etwas ungewöhnlich. Kann man in diesen Fällen nicht einfach Straße statt Staatsstraße schreiben? Wieder was gelernt. Ich dachte das wär überall so mit den Staatsstraßen und nicht nur hier in Sachsen (bzw. in Bayern). Ich könnte auch Landes-/Staatsstraße schreiben oder einfach secondary. Straße wär mir zu wenig und da würde ich nicht gleich drauf kommen, dass es um die secondarys geht. Grüße Christoph signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mal wieder: Mapnik und Schwarzwald
Sven Geggus schrieb: beim Schwarzwald Multipolygon hat sich imemr noch nix getan. Alle Dörfer sind im Grünen. Ist das Multipolygon falsch oder ist Mapnik buggy? Mein See mit Inseln wird ja auch korrekt dargestellt: http://www.openstreetmap.org/?lat=49.09674lon=8.54871zoom=16layers=B000FTF das problem existiert, seitdem mapnik innerhalb ein paar stunden neu rendert sobald daten geändert wurden... irgendwie hat er da probleme mit den multipolygonen. wenn der komplette datensatz neu gerendert wird, ist es dann wieder bis zur näxten änderung ok. siehe: http://www.mail-archive.com/talk-de@openstreetmap.org/msg38685.html oder: http://www.mail-archive.com/t...@openstreetmap.org/msg14227.html oder: http://www.mail-archive.com/t...@openstreetmap.org/msg14552.html Kann man da als mapper was machen oder muss man da in osm2pgsql rumhacken? keine daten mehr ändern machen ;-) Irgendwo konnte man doch mal mapnik bugs reporten, oder? http://trac.openstreetmap.org/ grüße frank ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Darstellungsform der Kreisel
Jan Tappenbeck schrieb: Moin ! vor Wochen gab es schon einmal eine Diskussion über die Arbeitsweise des Kreisel-Tools in JOSM und die Tatsache dass immer im Uhrzeigersinn, per default, gezeichnet wird. Gary68 hat mal die Kreisel allein in Spanien [1] analysiert und über 500 falsche Richtungen ermittelt. Alle die ich mir bisher angesehen habe sind dann auch falsch herumgezeichnet - vermutlich wegen Unachtsamkeit der Anwender. Es sollte daher nochmal über die Lösung dieses Problems nachgedacht werden. Es sollte auf dieser Welt weniger Kriege geben :-) https://josm.openstreetmap.de/newticket (zur Not auch in Deutsch ein neues Ticket eintragen). Oder gibt es da schon ein Ticket zu? Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mal wieder: Mapnik und Schwarzwald
Frank Sautter openstreet...@sautter.com wrote: das problem existiert, seitdem mapnik innerhalb ein paar stunden neu rendert sobald daten geändert wurden... irgendwie hat er da probleme mit den multipolygonen. wenn der komplette datensatz neu gerendert wird, ist es dann wieder bis zur näxten änderung ok. Sieht also ganz so aus, als ob wir uns da dann für die Mapping Tour mit dem SWR einen schlecht geeigneten Ort ausgesucht hätten. http://www.openstreetmap.org/?lat=48.89653lon=8.47051zoom=16layers=B000FTF Wenn ich die genannten Postings richtig interpretiere ist das ein Bug im inkrementellen Teil von osm2pgsql. Sven -- Software is like sex; it's better when it's free (Linus Torvalds) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tlw. erledigt....
Jan Tappenbeck schrieb: hi ! das war leider nicht die ursache ! gruß Jan :-) Das ließ mir jetzt keine Ruhe. ;-) Also getestet: Es liegt am Aufbau der TXT-Datei. Du hast zwar bei den Markern einen titel, aber keine description eingetragen (zwei Tabulatoren hintereinander), damit funzt es nicht. Es muß anscheinend bei der description mindestens ein Zeichen (z. B. Leerzeichen) eintragen werden, dann geht es. Das komplette Weglassen der description-Spalte brachte keinen Erfolg. Anscheinend sind die Spalten nicht 'possible', wie die Doku besagt, sondern 'mandatory'. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitätssicherung - unbenannte Objek te
Jetzt gibt es auch eine Übersicht unter http://wiki.openstreetmap.org/wiki/SearchNoNamePOI Die Pfade zu unten mußten nochmal angepaßt werden ! jetzt auch Köln und Müchen, Bayern und NRW Jan Tappenbeck schrieb: habe noch einige draufgelegt http://www.tappenbeck.net/osm/quality/poi_noname/schleswig-holstein/ http://www.tappenbeck.net/osm/quality/poi_noname/grossraum_kiel/ http://www.tappenbeck.net/osm/quality/poi_noname/grossraum_luebeck/ eine uebersichtsseite folgt ! Gruß Jan :-) Jan Tappenbeck schrieb: Moin ! ich habe mich auch an einem Tool versucht für das Auffinden von unbenannten Objekten - wenn schon Elemente in der Karte, dann auch mit dem entsprechenden Namen. Eine erste Auswertung für Hamburg findet sich unter http://www.tappenbeck.net/osm/quality/poi_noname/hamburg/ Bei Bedarf kann ich auch die anderen Bundesländer rechnen lassen oder Auszüge wenn die Bereiche zu groß sind. Schaut es Euch an und wenn es etwas zu verbessern gibt melden. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitätssicherung - unbenannte Objek te
Jan Tappenbeck schrieb: Jetzt gibt es auch eine Übersicht unter http://wiki.openstreetmap.org/wiki/SearchNoNamePOI Kannst Du das Ding nicht auch für Adressen erweitern? Ein Imbiss ohne Adresse ist ... lahm :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tiles-Generierung mit Mapnik momentan wieder lahm?
Hi, ich hab mitbekommen, dass letztens das Intervall verkürzt wurde, in dem neue Tiles generiert werden. Das hat dann den erfreulichen Effekt gehabt, dass ich teilweise bereits nach 10min die ersten Auswirkungen auf der Karte gesehen hab. Jetzt scheint das aber nicht mehr der Fall zu sein. Ich hab Anfang der Woche was geändert und sehe noch immer keine Anpassung der Mapnik-Karte. Osmarender frissts aber bereits. Was ist da los? Es geht konkret um die Waldwege in diesem Gebiet: http://www.openstreetmap.org/?lat=48.89935lon=8.77967zoom=17layers=0B00FTF Gruß, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM-Gebäude in Google-Pseudo-3D ?
Hallo Community, http://artem.dev.openstreetmap.org/files/osm_3d.png weiß jemand Näheres? Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiles-Generierung mit Mapnik momentan wieder lahm?
ich hab mitbekommen, dass letztens das Intervall verkürzt wurde, in dem neue Tiles generiert werden. Das hat dann den erfreulichen Effekt gehabt, dass ich teilweise bereits nach 10min die ersten Auswirkungen auf der Karte gesehen hab. Jetzt scheint das aber nicht mehr der Fall zu sein. Ich hab Anfang der Woche was geändert und sehe noch immer keine Anpassung der Mapnik-Karte. Osmarender frissts aber bereits. Was ist da los? Das ist wegen Arbeiten am Server vorübergehend bis morgen außer Betrieb gesetzt: http://lists.openstreetmap.org/pipermail/talk/2009-May/036875.html -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Gebäude in Google-Pseudo-3D ?
http://artem.dev.openstreetmap.org/files/osm_3d.png weiß jemand Näheres? Das ist ein Test von Artem Pavlenko, den er hier angekündigt hat: http://lists.openstreetmap.org/pipermail/talk/2007-September/018019.html Hier geht der Thread weiter: http://lists.openstreetmap.org/pipermail/talk/2007-September/018059.html -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] [Fwd: [OSM-Presse] EARLY BOOKING 2009 - LEDA HOTEL GREECE]
Hallo, warum werden denn neuerdings über die Presseliste Spam-Mails versendet? André ---BeginMessage--- EARLY BOOKING 2009 - LEDA HOTEL OFFER EARLY BOOKING 2009 LEDA BEACH CLUB HORTO - ARGALASTI - PELION This offer applies only for a limited number of bookings for each type of accommodation this year Built amphitheatrically in a beautiful beach of Pagassetic Gulf in Pelion peninsula Leda complex is found just 300 metres away from the centre of the picturesque village of Horto. It consists of houses constructed in Pelion architectural style all looking on to the sea and the small islands of Pagassetic Gulf. These houses have rooms, studios, apartments, suites and independent villas. Leda complex has its own restaurant and bar by the beach. You can also use FREE OF CHARGE the swimming pool, children's pool, children's playground, tennis court, mini golf, table tennis, outdoor chess, wireless internet, digital safes. Yoga and diving lessons, water sports like canoeing, Jacuzzi and sauna, windsurfing and hiring of yachts are also available paying only a small fee. It will be our pleasure to welcome you at this wonderful place. Accommodation per day (in euro) TYPEROOM SWAN ROOM LEDA STUDIO ERATO STUDIO LEDA APPARTMENT ERATO APPARTMENT LEDA DISTANCE FROM THE SEA 90 - 105 m. 45 -85 m. 6 -9 m. 10 -35 m. 6 -9 m.10 -45 m. PERIODSEA VEW SEA VEWSEA VEWSEA VEWSEA VEWSEA VEW 3/5 - 27/6 6/9 - 31/10454550556065 28/6 - 4/7 606070758090 5/7 - 11/7 65708090100110 12/7 - 25/7 7580100120130135 26/7 - 1/8 8085110125135145 2/8 - 8/8 16/8 - 22/895100125130140150 9/8 - 15/8 100110130140150165 23/8 - 29/8 707595115130140 30/8 - 5/9 505055606570 OPTIONALLY Breakfast: 6, 00 Euros per person/per day buffet. Half board: 16,00 Euros per person/per day buffet. Children under the age of 4 (breakfast / half board): FREE Children from 4 to 10 years old: 50% discount on table board. For any further queries please do contact us. We are at your disposal. Web site: www.ledahotel.gr / www.ledapelion.com Email: i...@ledapelion.com /i...@ledahotel.gr TEL: 0030 24210 27931 - 24230 65500 Fax: 0030 24210 38008 In case you do not wish to receive newsletters from Leda Hotel, please press Here and Send ___ Presseteam mailing list presset...@lists.openstreetmap.de http://lists.openstreetmap.de/mailman/listinfo/presseteam ---End Message--- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Gebäude in Google-Pseudo-3D ?
Christian Koerner schrieb: Mapnik hat seit ein paar Monaten ein Building-Symbolizer: http://trac.mapnik.org/wiki/BuildingSymbolizer Hallo, wird denn das Kartenbild in den größten Zoomstufen in Zukunft allgemein angepasst wie in der dort gezeigten Grafik? Ich fände das sehr löblich! André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Gebäude in Google-Pseudo-3D ?
Christian Koerner schrieb: Mapnik hat seit ein paar Monaten ein Building-Symbolizer: http://trac.mapnik.org/wiki/BuildingSymbolizer Cool, wusste ich noch gar nicht. Danke! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitätssicherung - unbenannte Objek te
hallo tobias, willst du nur auf die hausnummer testen oder wie tief? sollte vom grundsatz kein problem sein - hatte ich auch schon einmal darüber nachgedacht bloss die liste wird sicherlich explodieren ! lass uns mal abwarten ob andere das auch für notwendig halten. gruß Jan :-) Tobias Wendorff schrieb: Jan Tappenbeck schrieb: Jetzt gibt es auch eine Übersicht unter http://wiki.openstreetmap.org/wiki/SearchNoNamePOI Kannst Du das Ding nicht auch für Adressen erweitern? Ein Imbiss ohne Adresse ist ... lahm :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Worldfile vom 13.Mai 2009
Hallo, die neuen Daten liegen wie immer zum Download bereit unter: http://wiki.openstreetmap.org/wiki/User:Computerteddy -- Viele Gruesse Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tlw. erledigt....
Hallo Georg, vielen Dank für den Hinweis. Hast Du jetzt noch eine Idee warum die Popups aufgehen - aber keinen Inhalt haben ??? Datendatei ist an derselben position geblieben. Gruß Jan :-) Georg Feddern schrieb: Jan Tappenbeck schrieb: hi ! das war leider nicht die ursache ! gruß Jan :-) Das ließ mir jetzt keine Ruhe. ;-) Also getestet: Es liegt am Aufbau der TXT-Datei. Du hast zwar bei den Markern einen titel, aber keine description eingetragen (zwei Tabulatoren hintereinander), damit funzt es nicht. Es muß anscheinend bei der description mindestens ein Zeichen (z. B. Leerzeichen) eintragen werden, dann geht es. Das komplette Weglassen der description-Spalte brachte keinen Erfolg. Anscheinend sind die Spalten nicht 'possible', wie die Doku besagt, sondern 'mandatory'. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitätssicherung - unbenannte Objek te
Jan Tappenbeck schrieb: sollte vom grundsatz kein problem sein - hatte ich auch schon einmal darüber nachgedacht bloss die liste wird sicherlich explodieren ! Nein, auf Karlsruhe-Schema. lass uns mal abwarten ob andere das auch für notwendig halten. Nunja, bis dahin hab ich's auch selbst fertig. Trotzdem danke :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitätssicherung - unbenannte Objekt e
Großartig, lässt du das bitte auch für Berlin berechnen? 2009/5/14 Jan Tappenbeck o...@tappenbeck.net: Jetzt gibt es auch eine Übersicht unter http://wiki.openstreetmap.org/wiki/SearchNoNamePOI Die Pfade zu unten mußten nochmal angepaßt werden ! jetzt auch Köln und Müchen, Bayern und NRW Jan Tappenbeck schrieb: habe noch einige draufgelegt http://www.tappenbeck.net/osm/quality/poi_noname/schleswig-holstein/ http://www.tappenbeck.net/osm/quality/poi_noname/grossraum_kiel/ http://www.tappenbeck.net/osm/quality/poi_noname/grossraum_luebeck/ eine uebersichtsseite folgt ! Gruß Jan :-) Jan Tappenbeck schrieb: Moin ! ich habe mich auch an einem Tool versucht für das Auffinden von unbenannten Objekten - wenn schon Elemente in der Karte, dann auch mit dem entsprechenden Namen. Eine erste Auswertung für Hamburg findet sich unter http://www.tappenbeck.net/osm/quality/poi_noname/hamburg/ Bei Bedarf kann ich auch die anderen Bundesländer rechnen lassen oder Auszüge wenn die Bereiche zu groß sind. Schaut es Euch an und wenn es etwas zu verbessern gibt melden. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tlw. erledigt....
Moin, Am Donnerstag 14. Mai 2009 16:08:48 schrieb Jan Tappenbeck: Hallo Georg, vielen Dank für den Hinweis. Hast Du jetzt noch eine Idee warum die Popups aufgehen - aber keinen Inhalt haben ??? Kann es sein, daß der Text die gleiche Farbe wie der Hintergrund hat (weiß)? Wenn ich mit gedrückter Maustaste drüberfahre wir der Inhalt markiert und damit sichtbar. Deine Zeichenkodierung scheint auch nicht zu stimmen, bei Umlauten sehe ich da seltsame Zeichen. Grüße, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] doppelte Relationen vermeiden
Hallo, bin beim Erstellen von Kreis- und Landstraßen-Relationen auf schon vorhandene mit einer anderen ID gestoßen. Wie kann ich nun beide Relationen zu einer Verschmelzen, bzw wie kann ich im Voraus schon herausfinden, ob es eine spezielle schon gibt? Gruß Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Amateure bei Google
http://maps.google.de/maps?q=51.642178,+12.046037 pff ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Amateure bei Google
ironie on Das kommt davon wenn google die daten bei OSM holt Wurde sicher mit Potlatch erstellt. /ironie off Tobias Wendorff wrote: http://maps.google.de/maps?q=51.642178,+12.046037 pff ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Garmin Version der Wanderkarte für ga nz Deutschland
Hi! Die Garmin-Version der Reit- und Wanderkarte ist jetzt für ganz Deutschland verfügbar, sozusagen meine OSM-Version der Topo Deutschland. Download über Wiki oder topo.geofabrik.de. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Amateure bei Google
Tobias Wendorff schrieb: http://maps.google.de/maps?q=51.642178,+12.046037 Ich verstehe den Witz nicht. Magst Du ihn erklären? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Amateure bei Google
ganz einfach, da fehlt ein Stück Schienenweg. wenn man den Ausschnitt etwas verschiebt, erkennt man das: http://maps.google.de/maps?ie=UTF8ll=51.644269,12.046616z=16 Johann H. Addicks schrieb: Tobias Wendorff schrieb: http://maps.google.de/maps?q=51.642178,+12.046037 Ich verstehe den Witz nicht. Magst Du ihn erklären? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Gebäude in Google-Pseudo-3D ?
André Reichelt schrieb: wird denn das Kartenbild in den größten Zoomstufen in Zukunft allgemein angepasst wie in der dort gezeigten Grafik? Ich fände das sehr löblich! Dann heisst das zukünftig: Gebäudehöhen mit erfassen und Dachformen klassifizieren... -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Gebäude in Google-Pseudo-3D ?
Johann H. Addicks schrieb: Dann heisst das zukünftig: Gebäudehöhen mit erfassen und Dachformen klassifizieren... Ich wollte eher auf die Parkplätze und ähnliches anspielen. André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Grün, grüner, am Grünsten (wa r: Mal wieder: Mapnik und Schwarzwald)
Hallo! Wenn Ihr Multipolygon-Probleme analysieren wollt, schaut Euch mal auf der Wanderkarte um. Die Waldflächen dort sind halbtransparent gerendert, so daß man noch einige Merkwürdigkeiten mehr erkennen kann. Manche Wälder werden mehrfach gerendert und sind entsprechend dunkler. Lustige Artefakte gibt es hier: http://topo.geofabrik.de/?zoom=12lat=49.00407lon=9.46706 http://topo.geofabrik.de/?zoom=11lat=50.76684lon=14.00785 Hier ein besonders interessanter Fall, in dem die Lichtungen erst mal korrekt ausgeschnitten werden und dann nochmal der ganze Wald ohne Lichtungen drübergerendert wird. http://topo.geofabrik.de/?zoom=14lat=49.47613lon=11.6245 Die Karte ist mit den neusten Versionen von Mapnik und osm2pqsql ohne Inkremente gerendert. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tlw. erledigt....
oh ! auf die idee bin ich noch nicht gekommen - danke! morgen mehr ! gruß Jan .-) Carsten Gerlach schrieb: Moin, Am Donnerstag 14. Mai 2009 16:08:48 schrieb Jan Tappenbeck: Hallo Georg, vielen Dank für den Hinweis. Hast Du jetzt noch eine Idee warum die Popups aufgehen - aber keinen Inhalt haben ??? Kann es sein, daß der Text die gleiche Farbe wie der Hintergrund hat (weiß)? Wenn ich mit gedrückter Maustaste drüberfahre wir der Inhalt markiert und damit sichtbar. Deine Zeichenkodierung scheint auch nicht zu stimmen, bei Umlauten sehe ich da seltsame Zeichen. Grüße, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM Composer V0.74
Hi! OSM Composer steht in der Version 0.74 zum Download bereit. http://wiki.openstreetmap.org/wiki/DE:OSM_Composer#Download Neu in Version V0.74 * Kartenränder werden immer geschnitten, auch bei kleinen Karten * Unterstützung für Karten mit unregelmäßigem Umriß * Option zur Auswertung aller Tags * POI-Verzeichnisse können erstellt werden * Fehlermeldungen von aufgerufenen Programmen werden mitgeschrieben * Kachelgröße kann pro Job eingestellt werden * Verbesserter Polygon-Splitter Algorithmus * Verbesserter Aufruf von srtm2osm für größere Konturdateien * Behoben: Wege mit POIs auf dem Weg verschwinden manchmal * Behoben: Höhenangaben an Konturen fehlen bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitätssicherung - unbenannte Objekt e
morgen mit dem berlin.osm gruß Jan :-) Christoph Henning schrieb: Großartig, lässt du das bitte auch für Berlin berechnen? 2009/5/14 Jan Tappenbeck o...@tappenbeck.net: Jetzt gibt es auch eine Übersicht unter http://wiki.openstreetmap.org/wiki/SearchNoNamePOI Die Pfade zu unten mußten nochmal angepaßt werden ! jetzt auch Köln und Müchen, Bayern und NRW Jan Tappenbeck schrieb: habe noch einige draufgelegt http://www.tappenbeck.net/osm/quality/poi_noname/schleswig-holstein/ http://www.tappenbeck.net/osm/quality/poi_noname/grossraum_kiel/ http://www.tappenbeck.net/osm/quality/poi_noname/grossraum_luebeck/ eine uebersichtsseite folgt ! Gruß Jan :-) Jan Tappenbeck schrieb: Moin ! ich habe mich auch an einem Tool versucht für das Auffinden von unbenannten Objekten - wenn schon Elemente in der Karte, dann auch mit dem entsprechenden Namen. Eine erste Auswertung für Hamburg findet sich unter http://www.tappenbeck.net/osm/quality/poi_noname/hamburg/ Bei Bedarf kann ich auch die anderen Bundesländer rechnen lassen oder Auszüge wenn die Bereiche zu groß sind. Schaut es Euch an und wenn es etwas zu verbessern gibt melden. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Etagen darstellen
Patrick Kolesa schrieb: lulu-...@gmx.de schrieb: Langfristig denke ich an eine Slippy-Map, die bei solchen Objekten ermöglicht, in den Ebenen zu blättern. Ich schlage vor, ebenfalls den Grundriss und Mauern zu vermessen, damit ich auch im Dunkeln navigieren kann. Besonders in meinem Keller würde mir das weiterhelfen, da stoße ich gerne mal gegen eine Wand ;) Das hatten wir doch hier schon diskutiert: http://openstreetmap.org/?lat=51.43077lon=7.11259zoom=17layers=B000FTT ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Worldfile vom 13.Mai 2009
Carsten Schwede schrieb: die neuen Daten liegen wie immer zum Download bereit unter: http://wiki.openstreetmap.org/wiki/User:Computerteddy Und der Mirror ist synchronisiert. Wenn ich noch Daten übersehen haben sollte bitte melden. Erreichbar unter http://osm.ammit.de bzw. direkt: http://osm.ammit.de/latest/ Gruß, Daniel. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Worldfile vom 13.Mai 2009
Daniel Senger schrieb: Und der Mirror ist synchronisiert. War ja klar. Fehler in die eigene URL eingebaut. Richtig ist: http://osm.ammit.de/osm/latest/ Gruß, Daniel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] doppelte Relationen vermeiden
Simon Kokolakis wrote: Hallo, bin beim Erstellen von Kreis- und Landstraßen-Relationen auf schon vorhandene mit einer anderen ID gestoßen. Wie kann ich nun beide Relationen zu einer Verschmelzen, bzw wie kann ich im Voraus schon herausfinden, ob es eine spezielle schon gibt? Ein einfachsten kann man die mit JOSM verschmelzen. Man öffne die Relationsbearbeitungsfenster beider Relationen gleichzeitig (!) , markiere bei einer Relation alle Straßen (1 Element im Relationsbearbeitungsfenster anwählen und ctrl+a drücken), wechsele zu dem anderen Relationsbearbeitungsfenster und benutze dort den ausgewählte Elemente hinzufügen Button. Dann noch ggf die Rolle manuell hinzufügen und speichern. Wenn alles geklappt hat, dann kannst Du die eine Relation löschen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Amateure bei Google
SLXViper slxvi...@gmx.net wrote: ganz einfach, da fehlt ein St?ck Schienenweg. Des g'hoert so! Ist Politik der DB Netz aus Gleisen, die sie meint nicht zu brauchen, zur Bestaetigung ein Stueckchen rauszuschnibbeln... Sicherlich ist dort google vieeel aktueller als das Luftbild! Und wenn dort zufaellig doch noch Linienverkehr angeboten wird: Ich wuerde da jetzt nicht mehr mitfahren wollen... ;-) MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiles-Generierung mit Mapnik momentan wieder lahm?
Das ist wegen Arbeiten am Server vorübergehend bis morgen außer Betrieb gesetzt: http://lists.openstreetmap.org/pipermail/talk/2009-May/036875.html Ah danke. Gut zu wissen. Hab mal die Mailingliste auch abonniert. Danke, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mal wieder: Mapnik und Schwarzwald
Sven Geggus li...@fuchsschwanzdomain.de wrote: Wenn ich die genannten Postings richtig interpretiere ist das ein Bug im inkrementellen Teil von osm2pgsql. Wie waere nochmal die theoretisch mapnik-kompatible Lichtungstagtik? Auszenring geschlossenes Polygon im Uhrzeigersinn role=outer landuse=forest, Lichtung geschlossenes Polygon gegen den Uhrzeigersinn role=inner landuse eigentlich obsolet? chh wundere mich auch shcon eine Weile, warum meine eine Lichtung in der Relation Hardtwald2 heute korrekt angezeigt wird in Mapnik, die anderen in der Relation Hardtwald aber nicht. Habe die eine jetzt mal probeweise doch mit denselben Tags wie die Auszengrenze getaggt, schaun mer mal... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
Johann H. Addicks addi...@gmx.net wrote: Dann heisst das zuk?nftig: Geb?udeh?hen mit erfassen und Dachformen klassifizieren... ...dachgauben- und schornsteingenau! MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Guenther Meyer schrieb: Am Dienstag 12 Mai 2009 schrieb Stefan Dettenhofer (StefanDausR): Mario Salvini schrieb: man kanns ja auch gerne *traffic*zone nennen oder gleich nur zone=, also zone=in_town:DE zone=out_of_town:DE zone=motorway:DE (zone=walk:DE) es geht also darum, neben geschwindigkeits-defaults auch noch andere standardeigenschaften bestimmer bereiche abzubilden, versteh ich das richtig? zone=motorway waere dann unnoetige redundanz, da entsprechende eigenschaften eigentlich bereits durch das highway=motorway tag impliziert werden. bei highway=trunk ist es aehnlich. zone=walk klingt fuer mich nach fussgaengerzone, und dafuer haben wir schon was. ausserdem ist das doch mit maxspeed=walk abgedeckt. oder gibt's da sonst noch irgendwelche besonderen eigenschaften ausser der schrittgeschwindigkeit? fuer zone=out_of_town sehe ich auch keinen grund; neben den geschwindigkeits-defaults kann ich da auch keine besonderen eigenschaften sehen. das einzige waere eben der ortsbereich, wo in der tat noch andere attribute gelten. aber deswegen einen separaten key einzufuehren - ich weiss nicht... man koennte ja durchaus den rest in ein maxspeed=town implizieren; oder explizit taggen... Da stellen sich mir alle Haare zu Berge... Höchstgeschwindigkeit=Stadt... Geschwindigkeit ist ein Wert der in Strecke pro Zeit definiert ist. Nichts anderes sollte hier zu finden sein! Dann kann man auch in 50 Jahren noch was mit den Daten anfangen! Wenn man erst anfangen muss zu rekonstruieren was damals town im Geschwindigkeitswert zu bedeuten hatte dann ist irgendwas falsch gelaufen... Implizieren kann man mit anderen Tags. Zuviel Intelligenz in die Tags packen zu wollen sorgt immer wieder zu unnötigen Fehlfunktionen wie es sich z.B. in fast regelmässigen Abständen bei den Waldflächen zeigt (siehe mal wieder: Schwarzwald und Mappnik). Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Garry schrieb: Guenther Meyer schrieb: Am Dienstag 12 Mai 2009 schrieb Stefan Dettenhofer (StefanDausR): Mario Salvini schrieb: man kanns ja auch gerne *traffic*zone nennen oder gleich nur zone=, also zone=in_town:DE zone=out_of_town:DE zone=motorway:DE (zone=walk:DE) es geht also darum, neben geschwindigkeits-defaults auch noch andere standardeigenschaften bestimmer bereiche abzubilden, versteh ich das richtig? zone=motorway waere dann unnoetige redundanz, da entsprechende eigenschaften eigentlich bereits durch das highway=motorway tag impliziert werden. bei highway=trunk ist es aehnlich. zone=walk klingt fuer mich nach fussgaengerzone, und dafuer haben wir schon was. ausserdem ist das doch mit maxspeed=walk abgedeckt. oder gibt's da sonst noch irgendwelche besonderen eigenschaften ausser der schrittgeschwindigkeit? fuer zone=out_of_town sehe ich auch keinen grund; neben den geschwindigkeits-defaults kann ich da auch keine besonderen eigenschaften sehen. das einzige waere eben der ortsbereich, wo in der tat noch andere attribute gelten. aber deswegen einen separaten key einzufuehren - ich weiss nicht... man koennte ja durchaus den rest in ein maxspeed=town implizieren; oder explizit taggen... Da stellen sich mir alle Haare zu Berge... Höchstgeschwindigkeit=Stadt... Geschwindigkeit ist ein Wert der in Strecke pro Zeit definiert ist. Nichts anderes sollte hier zu finden sein! Dann kann man auch in 50 Jahren noch was mit den Daten anfangen! Wenn man erst anfangen muss zu rekonstruieren was damals town im Geschwindigkeitswert zu bedeuten hatte dann ist irgendwas falsch gelaufen... Implizieren kann man mit anderen Tags. Zuviel Intelligenz in die Tags packen zu wollen sorgt immer wieder zu unnötigen Fehlfunktionen wie es sich z.B. in fast regelmässigen Abständen bei den Waldflächen zeigt (siehe mal wieder: Schwarzwald und Mappnik). Garry aber mit speedzone=* oder trafficzone=* oder zone:traffic=* kämst du schon zurecht, oder? Damit das aber Sinn macht müsstest du dich von der Idee loslösen überamm maxspeed zu taggen, sondern nur da, wo auch echte Schilder stehen :). Ne andere Sache: was mir gerade in den Kopf gekommen ist. Warum taggen wir in die autobahn-ähnlichen Strecken (also die mit gleicher Funktion nur halt eben nicht die Autbahnschilder) mit highway=motorway? Würde das die Realität sosehr verfälscht abbilden? Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Mario Salvini schrieb: Garry schrieb: Guenther Meyer schrieb: Am Dienstag 12 Mai 2009 schrieb Stefan Dettenhofer (StefanDausR): Mario Salvini schrieb: man kanns ja auch gerne *traffic*zone nennen oder gleich nur zone=, also zone=in_town:DE zone=out_of_town:DE zone=motorway:DE (zone=walk:DE) es geht also darum, neben geschwindigkeits-defaults auch noch andere standardeigenschaften bestimmer bereiche abzubilden, versteh ich das richtig? zone=motorway waere dann unnoetige redundanz, da entsprechende eigenschaften eigentlich bereits durch das highway=motorway tag impliziert werden. bei highway=trunk ist es aehnlich. zone=walk klingt fuer mich nach fussgaengerzone, und dafuer haben wir schon was. ausserdem ist das doch mit maxspeed=walk abgedeckt. oder gibt's da sonst noch irgendwelche besonderen eigenschaften ausser der schrittgeschwindigkeit? fuer zone=out_of_town sehe ich auch keinen grund; neben den geschwindigkeits-defaults kann ich da auch keine besonderen eigenschaften sehen. das einzige waere eben der ortsbereich, wo in der tat noch andere attribute gelten. aber deswegen einen separaten key einzufuehren - ich weiss nicht... man koennte ja durchaus den rest in ein maxspeed=town implizieren; oder explizit taggen... Da stellen sich mir alle Haare zu Berge... Höchstgeschwindigkeit=Stadt... Geschwindigkeit ist ein Wert der in Strecke pro Zeit definiert ist. Nichts anderes sollte hier zu finden sein! Dann kann man auch in 50 Jahren noch was mit den Daten anfangen! Wenn man erst anfangen muss zu rekonstruieren was damals town im Geschwindigkeitswert zu bedeuten hatte dann ist irgendwas falsch gelaufen... Implizieren kann man mit anderen Tags. Zuviel Intelligenz in die Tags packen zu wollen sorgt immer wieder zu unnötigen Fehlfunktionen wie es sich z.B. in fast regelmässigen Abständen bei den Waldflächen zeigt (siehe mal wieder: Schwarzwald und Mappnik). Garry aber mit speedzone=* oder trafficzone=* oder zone:traffic=* kämst du schon zurecht, oder? So lange es nicht zu Lasten des maxspeed-Tags geht ja. Damit das aber Sinn macht müsstest du dich von der Idee loslösen überamm maxspeed zu taggen, sondern nur da, wo auch echte Schilder stehen :). Warum? maxspeed ist für jeden Streckenabschnitt (in Deutschland) definiert, ob da ein Schild steht oder nicht. Die einzigen Ausnahmen sind die Autobahnen und autobahnähnliche ausgebaute Strassen. Ne andere Sache: was mir gerade in den Kopf gekommen ist. Warum taggen wir in die autobahn-ähnlichen Strecken (also die mit gleicher Funktion nur halt eben nicht die Autbahnschilder) mit highway=motorway? Würde das die Realität sosehr verfälscht abbilden? Ja. Für Autobahnen gilt Bauartbedingte Höchstgeschwindigkeit über 60km/h - das gilt für autobahnähnliche ausgebaute Strassen nur dann wenn es gleichzeitig auch Kraftfahrstrassen sind. Schönes Beispiel dafür ist die A65/B10/K irgendwas von Landau nach Karlsruhe Mitte (Autobahnauffahrt A5). Auf der Pfälzer Seite ist diese Strasse die für den Nutzer über den gesamten Abschnitt eine durchgänge vierspurige ausgebaute Autobahn ist eine echte Autobahn, nach dem Wörther Kreuz (Kreuzung mit der Autobahnähnlich ausgebauten B9) ist es nur noch eine autobahnähnlich ausgebaute Strasse die aber mit praktisch allen Fahrzeugen oberhalb Radfahrer /Mofas (Radwegnutzungspflicht) befahren werden darf da es auf 50km die einzigste dauerhafte Rheinquerungsmöglichkeit (es gibt noch 2-3 Fähren die aber nicht immer fahren)ist. ca. 1km nach der Rheinbrücke ist das ganze dann eine Kraftfahrstrasse wo wieder die Bauartbedingte Höchstgeschwindigkeit über 60km/h gilt. Abgesehen davon meine ich dass Autobahnen heute mit Standstreifen gebaut werden müsse, autobahnähnliche Strassen dagegen nicht. Un noch ein Unterschied: Autobahnen dürfen nur an den Ausfahrten verlassen werden. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues motorroad-Rendering verstaendlich?
Heiko Jacobs schrieb: Robert rob.foren+...@gmail.com wrote: Grund ist dann da eher das Aussperren bestimmter Fahrzeuge als das schnelle Vorankommen. Da tue ich mich dann schwer die mangels Verbindungscharakter h?her zu klassifizieren. ;-) Zugegeben, das kommt (sehr) selten vor. Behoerden sind manchmal sehr erfindungsreich beim Aussperren von nichtmotorisierten Verkehrsteilnehmern. Deswegen habe ich vorsichtshalber mal sec. und tert. mit reingenommen... Unclassified... Hmmm... Habe ich auch schon mal an einer Unterführung gesehen die so schmal war dass der Verkehr dort dauerhaft per Ampel-Einbahn geregelt war. Die Zufahrten waren auch sehr steil so dass weniger sportliche Radfahrer und andere langsame Fahrzeuge den Bereich nicht wieder schnell genug für den Gegenverkehr hätten räumen können. Die Unterführung war eine Verbindung zwischen zwei Mischgebieten eines Ortes mit sehr wenig Verkehr. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Garry schrieb: Mario Salvini schrieb: Garry schrieb: Guenther Meyer schrieb: Am Dienstag 12 Mai 2009 schrieb Stefan Dettenhofer (StefanDausR): Mario Salvini schrieb: man kanns ja auch gerne *traffic*zone nennen oder gleich nur zone=, also zone=in_town:DE zone=out_of_town:DE zone=motorway:DE (zone=walk:DE) es geht also darum, neben geschwindigkeits-defaults auch noch andere standardeigenschaften bestimmer bereiche abzubilden, versteh ich das richtig? zone=motorway waere dann unnoetige redundanz, da entsprechende eigenschaften eigentlich bereits durch das highway=motorway tag impliziert werden. bei highway=trunk ist es aehnlich. zone=walk klingt fuer mich nach fussgaengerzone, und dafuer haben wir schon was. ausserdem ist das doch mit maxspeed=walk abgedeckt. oder gibt's da sonst noch irgendwelche besonderen eigenschaften ausser der schrittgeschwindigkeit? fuer zone=out_of_town sehe ich auch keinen grund; neben den geschwindigkeits-defaults kann ich da auch keine besonderen eigenschaften sehen. das einzige waere eben der ortsbereich, wo in der tat noch andere attribute gelten. aber deswegen einen separaten key einzufuehren - ich weiss nicht... man koennte ja durchaus den rest in ein maxspeed=town implizieren; oder explizit taggen... Da stellen sich mir alle Haare zu Berge... Höchstgeschwindigkeit=Stadt... Geschwindigkeit ist ein Wert der in Strecke pro Zeit definiert ist. Nichts anderes sollte hier zu finden sein! Dann kann man auch in 50 Jahren noch was mit den Daten anfangen! Wenn man erst anfangen muss zu rekonstruieren was damals town im Geschwindigkeitswert zu bedeuten hatte dann ist irgendwas falsch gelaufen... Implizieren kann man mit anderen Tags. Zuviel Intelligenz in die Tags packen zu wollen sorgt immer wieder zu unnötigen Fehlfunktionen wie es sich z.B. in fast regelmässigen Abständen bei den Waldflächen zeigt (siehe mal wieder: Schwarzwald und Mappnik). Garry aber mit speedzone=* oder trafficzone=* oder zone:traffic=* kämst du schon zurecht, oder? So lange es nicht zu Lasten des maxspeed-Tags geht ja. Damit das aber Sinn macht müsstest du dich von der Idee loslösen überamm maxspeed zu taggen, sondern nur da, wo auch echte Schilder stehen :). Warum? maxspeed ist für jeden Streckenabschnitt (in Deutschland) definiert, ob da ein Schild steht oder nicht. Die einzigen Ausnahmen sind die Autobahnen und autobahnähnliche ausgebaute Strassen. aber genau das wäre doch gerade der Benefit, dennn wir mit einem Wert wie trafficzone=* erreichen können. Eben alle implizierten Geschwindigkeiten mit einem Platzhalter wie in_city oder out_of_town zu erfassen. Außerorts müsste mann dann anstatt eigentlich maxspeed:motorcar=100, maxspeed:hgv=60, etc. nur ein trafficzone=out_of_town:DE zu taggen und der rest könne an einer zentralen Stelle (ähnlich wie die maxspeed-Defaults in der Wiki) erfaßt werden. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] cartine topografiche per un principiante
brunetto ha scritto: Ciao a tutti! Ciao e benvenuto! Anche se e` da un po' che seguo il progetto sono nuovo e dilettante, sia per la parte di rilevazione che per la parte di gestione dei dati. Io mi faccio chiamare niubii... fai un po' tu! :-) Legandomi anche ad un altra mail (Info per GPS se non sbaglio), sarei molto interessato a scaricare/creare mappe del tipo IGM o Tabacco sia per zone tipo citta` che per montagna da usare (anche stampate) principalmente con il gruppo scout del mio paese, sia per la valenza educativa, che per l'accuratezza e la possibilita` di modifica: le cartine che reperiamo ultimamente sono spesso datate (anni 60) o lacunose. Ho letto una barca di documentazione sul wiki di osm e su altri siti riguardo alla possibilita` di creare mappe personalizzate includendo anche i dati della NASA (srtm) per creare le isoipse, ma faccio fatica ad orientarmi e trovare il sistema piu` efficace. OK. Qualcosa del tipo: http://wiki.openstreetmap.org/images/f/fa/Toposm_map1_crop.jpg Mi sembra che la cycle-map sia la cosa che si avvicina di piu`, ma avrei bisogno di integrare quello che manca e forse evidenziare meglio la parte pedonale! Leggendo le mail mi sembra di aver capito che si stava iniziando a fare qualcosa per l'Italia a partire da un progetto tedesco... Cosa consigliereste quindi per ottenere delle mappe (e magari aggiungere anche quello che manca) in modo non troppo complicato e lungo? Restiamo in contatto, vorrei fare la stessa cosa. Inizierei da qui: http://wiki.openstreetmap.org/wiki/TopOSM E` possibile, in modo semplice, aggiungere un reticolo UTM e ottenere una cartina in scala (diciamo) 1:25000? Certo. Se il tutto fosse abbastanza semplice potrei anche riuscire a coinvolgere altra gente e, perche' no, reclutare altri mappatori!:-P Non sara' semplice, non sara' breve. Pero' sara' interessante, almeno per me. Grazie!! e di che? Ciao /niubii/ Nessun virus nel messaggio in uscita. Controllato da AVG - www.avg.com Versione: 8.5.325 / Database dei virus: 270.12.27/2112 - Data di rilascio: 05/13/09 07:04:00 ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Dati cartografici Regione Emilia Romagna
2009/5/14 Edoardo 'Yossef' Marascalchi edoa...@edoardomarascalchi.it: tribunale, ma sto raggiungendo un grado di fastidio massimo al riguardo. Il fastidio è condiviso... Ero e rimango dell'opinione che le CTR siano parte integrante di atti legislativi e come tali libere da diritti. Mi piacerebbe darti ragione ma temo che non sia così semplice. Una CTR è effettivamente prodotta da un ente dello stato, ma non so sia mai stata approvata come atto legislativo. Solo in quel caso sarebbe esplicitamente esclusa dal diritto d'autore. Faccio un esempio: per quanto non conosca bene la legislazione UK, sospetto che la clausola le leggi non sono protette dal diritto d'autore (che esiste nel diritto italiano) non sia altro che il recepimento della Convenzione di Berna sul diritto d'autore. Per questo motivo sospetto che anche il diritto UK abbia una clausola analoga. Eppure la cartografia UK, prodotta dalla Ordnance Survey (che è un ente statale anche se con uno statuto un po' particolare) è sicuramente coperta dal diritto d'autore. Quindi temo che l'autorizzazione alla derivazione dalle CTR sia necessaria. D'altra parte nessuno ci vieta, e anzi sono totalmente d'accordo, di fare pressione e rumore affinché la cartografia prodotta dallo stato italiano, con i nostri soldi, sia resa disponibile con la licenza più liberale possibile. Negli Stati Uniti, dove lo Stato è mal visto (forse per questo), tutto ciò che è prodotto dalle amministrazioni deve essere rilasciato nel pubblico dominio. Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Sentieri CAI
2009/5/13 Stefano Salvador stefano.salva...@gmail.com: per le route: type=route route=hiking operator=C.A.I ref=[numero sentiero se esite] name=[nome sentiero se esiste] Ciao, stavo vedendo il tuo file .OSM. Lavoro impressionante! Unico appunto: hai usato name= per le route, invece di ref= Se lo apro con un editor di testi e vado verso il fondo del file (da riga 1424893) vedo che le relation sono taggate name=100 invece di ref=100 Ciao, Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Dati cartografici Regione Emilia Romagna
Federico Cozzi wrote: 2009/5/14 Edoardo 'Yossef' Marascalchi edoa...@edoardomarascalchi.it: Ero e rimango dell'opinione che le CTR siano parte integrante di atti legislativi e come tali libere da diritti. Eppure la cartografia UK, prodotta dalla Ordnance Survey (che è un ente statale anche se con uno statuto un po' particolare) è sicuramente coperta dal diritto d'autore. mischi pere con patate.. OS è il corrispondente, volendo, dell'IGM. Le CTR sono atti legislativi poiché mantengono informazioni sull'accatastamento e sono la base per ogni singolo provvedimento preso dall'amministrazione pubblica quando di parla di territorio. In teoria (ma occorrerebbe verificarlo) dovrebbero essere uno degli allegati ad ogni singolo atto aministratirvo che riguardi il territorio. Quindi temo che l'autorizzazione alla derivazione dalle CTR sia necessaria. D'altra parte nessuno ci vieta, e anzi sono totalmente d'accordo, di fare pressione e rumore affinché la cartografia prodotta dallo stato italiano, con i nostri soldi, sia resa disponibile con la licenza più liberale possibile. Negli Stati Uniti, dove lo Stato è mal visto (forse per questo), tutto ciò che è prodotto dalle amministrazioni deve essere rilasciato nel pubblico dominio. io procederei in parallelo: contattiamo l'amministrazione e ci facciamo dare l'autorizzazione, ma cominciamo in ogni caso ad importare i dati. poi se l'amminstrazione dovesse negarci l'autorizzazione, che ci porti in tribunale, e vediamo se veramente i dati sono protetti o meno. Mal che vada cosa succede: cancelliamo l'italia? con tutta la pubblicità che ci faremmo, in meno di un'anno la recuperiamo... Edoardo -- Edoardo 'Yossef' Marascalchi ICT Consultant Tel +39.347.008.00.02 website: http://www.edoardomarascalchi.it skype: My status skype:asca_edom?call ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Dati cartografici Regione Emilia Romagna
2009/5/14 Edoardo 'Yossef' Marascalchi edoa...@edoardomarascalchi.it: mischi pere con patate.. OS è il corrispondente, volendo, dell'IGM. Le CTR sono atti legislativi poiché mantengono informazioni sull'accatastamento e sono la base per ogni singolo provvedimento preso Mica vero, la CTR della Lombardia contiene laghi, fiumi e punti quotati che non sono atti legislativi (mi viene in mente quello stato americano che, tantissimi anni fa, decretò per legge che pigreco=3 :-) Insomma la CTR, o per lo meno alcuni suoi layer, è molto simile alle carte OS. Diverso il discorso degli usi del suolo, su cui effettivamente la CTR è normativa, non descrittiva. dall'amministrazione pubblica quando di parla di territorio. In teoria (ma occorrerebbe verificarlo) dovrebbero essere uno degli allegati ad ogni singolo atto aministratirvo che riguardi il territorio. Esatto: se troviamo un atto legislativo che incorpora la CTR come allegato abbiamo vinto. Però, così alla cieca, non lo so. Bisognerebbe fare un lavoro di ricerca bibliografica. io procederei in parallelo: contattiamo l'amministrazione e ci facciamo dare l'autorizzazione, ma cominciamo in ogni caso ad importare i dati. Tutta 'sta fretta è cosa buona, ma dopotutto abbiamo già 3 CTR (Lombardia, Veneto, FVG) da importare + la Toscana da ricalcare, potremmo accontentarci per il momento? Considerando che alcune CTR sono in un formato talmente bislacco (vedi FVG) che l'import è molto difficile. Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Dati cartografici Regione Emilia Romagna
Federico Cozzi wrote: Tutta 'sta fretta è cosa buona, ma dopotutto abbiamo già 3 CTR (Lombardia, Veneto, FVG) da importare + la Toscana da ricalcare, potremmo accontentarci per il momento? Considerando che alcune CTR sono in un formato talmente bislacco (vedi FVG) che l'import è molto difficile. assolutamente d'accordo, la mia era un'osservazione di principio! :D Edoardo -- Edoardo 'Yossef' Marascalchi ICT Consultant Tel +39.347.008.00.02 website: http://www.edoardomarascalchi.it skype: My status skype:asca_edom?call ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Dati cartografici Regione Emilia Romagna
Federico Cozzi wrote: 2009/5/14 Edoardo 'Yossef' Marascalchi edoa...@edoardomarascalchi.it: mischi pere con patate.. OS è il corrispondente, volendo, dell'IGM. Le CTR sono atti legislativi poiché mantengono informazioni sull'accatastamento e sono la base per ogni singolo provvedimento preso Mica vero, la CTR della Lombardia contiene laghi, fiumi e punti quotati che non sono atti legislativi il piano paesaggistico la usa come cartografia di base Edo -- Edoardo 'Yossef' Marascalchi ICT Consultant Tel +39.347.008.00.02 website: http://www.edoardomarascalchi.it skype: My status skype:asca_edom?call ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Dati cartografici Regione Emilia Romagna
Il mio scopo è solamente quello di aggiungere alla lista dei dati disponibili anche quelli dell' Emilia Romagna, principalmente quei dati che è praticamente impossibile ricavarsi sul campo contrariamente alle strade. Anche se sono d' accordo che sono dati nostri in quanto pagati da tutti noi, credo che la strada sia quella di fare rumore e pressione affinchè siano liberalizzati per l' uso su OSM. Vorrei però capire bene, ma è colpa mia perchè non sono andato a studiarmi le varie licenze OSM presenti e future, che cosa dire all' interlocutore rispetto a questo punto. Ciao Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Dati cartografici Regione Emilia Romagna
Mi sembra ci sia un po' di confusione. Edo, le CTR non hanno nulla a che vedere con l'accatastamento (nel senso di dati catastali?!) Se posso, visto che ho avuto modo di lavorare direttamente con RER negli ultimi 5 anni, suggerisco di contattare due persone: - Sergio Tinari, responsabile dell'Archivio cartografico [1] - Roberto Gavaruzzi, dirigente di riferimento per le attività connesse alla CTR [2] [1] http://archiviocartografico.regione.emilia-romagna.it/bookshop/dove?id_sessione= [2] http://www.regione.emilia-romagna.it/ermes/cercaregione/persone_ris.asp?nome=cognome=gavarootRicerca=R001show_persona=2555#2555 pg Il 14 maggio 2009 11.07, Simone Cortesi sim...@cortesi.com ha scritto: 2009/5/14 Edoardo 'Yossef' Marascalchi edoa...@edoardomarascalchi.it: Quindi temo che l'autorizzazione alla derivazione dalle CTR sia necessaria. D'altra parte nessuno ci vieta, e anzi sono totalmente d'accordo, di fare pressione e rumore affinché la cartografia prodotta dallo stato italiano, con i nostri soldi, sia resa disponibile con la licenza più liberale possibile. Negli Stati Uniti, dove lo Stato è mal visto (forse per questo), tutto ciò che è prodotto dalle amministrazioni deve essere rilasciato nel pubblico dominio. io procederei in parallelo: contattiamo l'amministrazione e ci facciamo dare l'autorizzazione, ma cominciamo in ogni caso ad importare i dati. poi se l'amminstrazione dovesse negarci l'autorizzazione, che ci porti in tribunale, e vediamo se veramente i dati sono protetti o meno. Mal che vada cosa succede: cancelliamo l'italia? con tutta la pubblicità che ci faremmo, in meno di un'anno la recuperiamo... sono totalmente daccordo con te edoardo. cio' che le amm. non volgiono avvenga (giustamente) è che qualcuno si metta a vendere dei libri con stampate sopra le carte tecniche regionali. di tutti quelli che da me sono stati approcciati, nessuno ha mai avuto nulla da ridire sull'uso del dato sottostante. infatti ho una percentuale di successo del 100% con tutte le amministrazioni con cui ho parlato...e ottenuto. molti ritengono che una volta pubblicato su internet, il dato sia libero per ogni utilizzo a parte la rivendita diretta as is. (secondo me giusto). FVG ha visto il nostro arrivo come una opportunità, stanno usando i dati che gli sono stati forniti in formato shp e in wgs84 e stanno valutando di passare al software libero tramite gvsig. che mi portino in tribunale: li sto aspettando. stiamo cambiando il mondo...un nodo alla volta. :) -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- Piergiorgio Cipriano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Sentieri CAI
Unico appunto: hai usato name= per le route, invece di ref= Se lo apro con un editor di testi e vado verso il fondo del file (da riga 1424893) vedo che le relation sono taggate name=100 invece di ref=100 l'ho fatto per vedere se eravate attenti :-) scherzi a parte nello script che ho preparato per l'upload faccio le cose giuste, o così almeno spero, per ora l'ho sto provando sul sito dev e sembra funzionare. Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Dati cartografici Regione Emilia Romagna
2009/5/14 Piergiorgio Cipriano pg.cipri...@gmail.com: Se posso, visto che ho avuto modo di lavorare direttamente con RER negli ultimi 5 anni, suggerisco di contattare due persone: - Sergio Tinari, responsabile dell'Archivio cartografico [1] - Roberto Gavaruzzi, dirigente di riferimento per le attività connesse alla CTR [2] dimenticavo una cosa nella ultima mail: non ho proseguito nel mio contattare le varie Regioni per un solo motivo: volevo aspettare di avere qualche risultato piu' tangibile con i dati gia' disponibili (veneto, friuli e lombardia). personalmente non me la sento di andare avanti a chiedere altri dati, senza aver fatto gran parte del lavoro con quelli gia' disponibili. Grazie a tutti voi...pochi casi degnissimi di nota: Stefano Salvador e Christian Pellegrin (per FVG), Roberto Navoni (di Lasernavigation per i confini dell'istat), Cristiano Giovando e Davide Zizioli (per il supporto omnicomprensivo a me - che sono capra dei GIS), Flavio Rigolon (per le faccende vicentine) tolti questi, che ringrazio pubblicamente sempre e comunque, non mi pare ci sia stato molto interesse in italia nei confronti della liberazione dei dati per il successivo inserimento in OSM. non a caso, parlando con gli altri della Foundation, avevo proposto e appoggiato la creazione del gruppo di supporto all'import dati. -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Dati cartografici Regione Emilia Romagna
2009/5/14 Simone Cortesi sim...@cortesi.com: sono totalmente daccordo con te edoardo. Io sono totalmente d'accordo con te Simone, che però sei totalmente d'accordo con Edoardo con cui io non sono totalmente d'accordo... C'è un problema :-) Quello che fai tu - Simone - mi sembra l'approccio migliore: contattare un ente locale, spiegargli cosa vogliamo fare con i loro dati, ottenere l'autorizzazione e usarli. Come dici tu il successo è vicino al 100%, quindi mi sembra un ottimo approccio. L'idea di Edo, cioè di iniziare a usare i dati prima di ottenere l'autorizzazione, mi sembra un po' rischiosa: se - chiedendo il permesso - si ottiene sempre sì nel 100% dei casi, forse è meglio seguire questa prassi un po' macchinosa ma più sicura. Dopotutto non stiamo con le mani in mano: abbiamo già un po' di Regioni su cui lavorare. Nel frattempo si possono far partire richieste verso altre regioni, ad esempio l'Emilia Romagna che - vendendo già i suoi dati su CD - mi sembra sufficientemente tecnologica per affrontare un discorso del genere. Ciao Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Dati cartografici Regione Emilia Romagna
2009/5/14 alberto albertobon...@libero.it: Vorrei però capire bene, ma è colpa mia perchè non sono andato a studiarmi le varie licenze OSM presenti e future, che cosa dire all' interlocutore rispetto a questo punto. Cercherei di non fare riferimento alle licenze di OSM che sono un po' ballerine... Forse la cosa migliore è studiare l'approccio di Simone (a proposito, quando ci mandi la scansione della richiesta e dell'autorizzazione? vogliamo iniziare l'import!) in modo che la richiesta sia agnostica Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] nuovo gruppo di lavoro OSM
Sono qui a chiedervi, se c'e' qualcuno che, condividendo questi scopi ed essendo un esperto gis+osm, possa essere interessato e volenteroso di far parte dell'anima tecnica del gruppo. A quanto pare io sono già coinvolto nella cosa con il lavoro che sto facendo per il FVG, non ho il tempo però per occuparmi della cosa in modo ufficiale, sono pronto però a dare una mano quando trovo il tempo e naturalmente a sfruttare tutto ciò che ne viene fuori ;-) Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Dati cartografici Regione Emilia Romagna
2009/5/14 Simone Cortesi sim...@cortesi.com: dimenticavo una cosa nella ultima mail: non ho proseguito nel mio contattare le varie Regioni per un solo motivo: volevo aspettare di avere qualche risultato piu' tangibile con i dati gia' disponibili (veneto, friuli e lombardia). Mi aggancio a questo thread perché sarebbe utile sapere quali regioni/provincie/comuni/altro_ente_pubblico sono già stati contattati, quali hanno concesso l'autorizzazione, quali no, dove si trovano i dati, ecc. Mi sembra che la regione dove vivo io, il Piemonte, non abbia concesso i dati, ma non sono riuscito a trovare specifiche informazioni in merito. E' possibile creare una apposita pagina sul wiki per monitorare questa attività? Grazie. Ciao, Andrea. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] osm live
questo me l'ero perso: http://datenkueche.com/osmlive/ mappa con contributor live...da un senso di calore vedere tutte quelle persone che migliorano la mappa. :) -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] sito openstreetmap.it
visto le manifestazioni di interesse che ho ricevuto (più di quante pensassi) vorrei, in attesa di aggiornare WP e Joomla e quindi aprire ai vostri contributi, sentire da voi come vorreste organizzati i contenuti tra CMS (Joomla) e blog (Wordpress).. esprimete le vostre opinioni Edo -- Edoardo 'Yossef' Marascalchi ICT Consultant Tel +39.347.008.00.02 website: http://www.edoardomarascalchi.it skype: My status skype:asca_edom?call ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] osm live
Simone Cortesi wrote: questo me l'ero perso: http://datenkueche.com/osmlive/ mappa con contributor live...da un senso di calore vedere tutte quelle persone che migliorano la mappa. :) tra parentesi.. nel blog (blog.openstreetmap.org) ho creato una sezione di link con usi reali di OSM.. se avete qualcosa da segnalarmi ... Edo -- Edoardo 'Yossef' Marascalchi ICT Consultant Tel +39.347.008.00.02 website: http://www.edoardomarascalchi.it skype: My status skype:asca_edom?call ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] M(')appare Cologno
Ebbene sì, ne ho avuto conferma ieri sera: M(')appare Milano può
finalmente ufficialmente sconfinare.
Info: http://wiki.openstreetmap.org/wiki/Milano#M.27appare_Cologno
Indicate sul wiki le vostre presenze!
Teniamoci in contatto per definire gli ultimi dettagli.
Buona giornata
Carlo
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\` /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] M(')appare Cologno
Il 14/05/2009 13:46, Carlo Stemberger ha scritto: Info: http://wiki.openstreetmap.org/wiki/Milano#M.27appare_Cologno Scusate, questo è il link corretto: http://wiki.openstreetmap.org/wiki/Milano#M.28.27.29appare_Cologno -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\` /\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] strade extraurbane non pavimentate
Come vi regolate nel taggare strade extraurbane di campagna con pavimentazione in ghiaino? Le mettete come hoghway=unclassified o come track? Premetto, non sono piste per trattori, parlo di strade non asfaltate. direte che mi sono risposto da solo, ma ho il dubbio, il rendering non le distingue dalle asfaltate e la differenza c'è... Ciao Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] strade extraurbane non pavimentate
2009/5/14 alberto albertobon...@libero.it: Come vi regolate nel taggare strade extraurbane di campagna con pavimentazione in ghiaino? Le mettete come hoghway=unclassified o come track? Premetto, non sono piste per trattori, parlo di strade non asfaltate. direte che mi sono risposto da solo, ma ho il dubbio, il rendering non le distingue dalle asfaltate e la differenza c'è... Io le traccio come highway=track e tracktype=grade1. http://wiki.openstreetmap.org/wiki/Track Track: Roads for agricultural use [...] http://wiki.openstreetmap.org/wiki/Key:tracktype grade1: Paved track or heavily compacted hardcore. Ciao, Andrea. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] strade extraurbane non pavimentate
Andrea Musuruane ha scritto: Io le traccio come highway=track e tracktype=grade1. http://wiki.openstreetmap.org/wiki/Track Track: Roads for agricultural use [...] http://wiki.openstreetmap.org/wiki/Key:tracktype grade1: Paved track or heavily compacted hardcore. Ciao, Andrea. Mi sembra una buona scelta, la adotterò. Ciao alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] strade extraurbane non pavimentate
-Original Message- From: talk-it-boun...@openstreetmap.org [mailto:talk-it- boun...@openstreetmap.org] On Behalf Of Andrea Musuruane Sent: giovedì 14 maggio 2009 15.32 To: openstreetmap list - italiano Subject: Re: [Talk-it] strade extraurbane non pavimentate 2009/5/14 alberto albertobon...@libero.it: Come vi regolate nel taggare strade extraurbane di campagna con pavimentazione in ghiaino? Le mettete come hoghway=unclassified o come track? Premetto, non sono piste per trattori, parlo di strade non asfaltate. direte che mi sono risposto da solo, ma ho il dubbio, il rendering non le distingue dalle asfaltate e la differenza c'è... Secondo me dipende dall'uso, non dalla pavimentazione. Sono track se rispettano tre condizioni: - sono adibite prevalentemente ad uso agricolo o forestale - non hanno alcuna funzione di collegamento tra località diverse - sono abbastanza larghe da permettere il passaggio di mezzi di trasporto (altrimenti sono path). Altrimenti sono unclassified (o anche superiore, se a dispetto della pavimentazione sono sufficientemente importanti). In questo caso per specificare lo stato fisico della strada puoi usare chiavi come surface=*, smoothness=*, width o est_width. Ciao. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] I bivacchi ora si vedono
Grazie Martin, ora i bivacchi si vedono ad uno zoom utile, per lo meno sul layer Osmarender: http://www.openstreetmap.org/?lat=45.9341lon=7.5977zoom=14layers=0B00FTF Mi piacerebbe che si vedessero anche i rifugi - c'è qualcuno bravo con Inkscape o simili che sa produrre un'icona adeguata? Ciao, Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] osm live
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il giorno Thu, 14 May 2009 12:51:29 +0200 Simone Cortesi sim...@cortesi.com ha scritto: questo me l'ero perso: http://datenkueche.com/osmlive/ mappa con contributor live...da un senso di calore vedere tutte quelle persone che migliorano la mappa. :) È semplicemente meravigliosa ;) - -- Francesco de Virgilio *Ubuntu-it Member and Wiki Editor* mailto:frad...@ubuntu-it.org http://wiki.ubuntu-it.org/FrancescoDeVirgilio *Wikimedia projects contributor* http://en.wikipedia.org/wiki/User:Fradeve11 *OpenStreetMap Mapper* http://www.openstreetmap.org/user/Fradeve11 *Blog* http://fradeve.netsons.org Love - Peace - Freedom - Free Software GPG 0x6482E056 (FP B996 A12C BD52 2A9B CDD3 812D 462D 93B0 6482 E056) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoMPlQACgkQRi2TsGSC4FZwsgCgoRrOIEdGkNUpf7T9CnelQami e7UAn0X0c0kNPZqmp5u/SjPCK7I+2rU0 =o8uo -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] strade extraurbane non pavimentate
Alberto Nogaro ha scritto: Secondo me dipende dall'uso, non dalla pavimentazione. Sono track se rispettano tre condizioni: - sono adibite prevalentemente ad uso agricolo o forestale - non hanno alcuna funzione di collegamento tra località diverse - sono abbastanza larghe da permettere il passaggio di mezzi di trasporto (altrimenti sono path). Altrimenti sono unclassified (o anche superiore, se a dispetto della pavimentazione sono sufficientemente importanti). In questo caso per specificare lo stato fisico della strada puoi usare chiavi come surface=*, smoothness=*, width o est_width. Ciao. Beh, le strade che ho in mente dopotutto rispettano anche le condizioni per essere track: - sono strade che non collegano località o frazioni - sono abbastanza larghe da permettere il passaggio di mezzi di trasporto - sono utilizzate prevalentemente per uso agricolo o per accesso a fondi agricoli. Mi sembra importante comunque differenziarle dalle asfaltate, altrimenti si finisce a visualizzarle come fa Google dove sembrano ottime e comode strade anche dei tratturi erbosi tra i campi, solo perchè hanno un nome (e magari anche una targa stradale, caso visto personalmente) :-) Ciao Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] strade extraurbane non pavimentate
2009/5/14 albertobonati albertobon...@libero.it: Beh, le strade che ho in mente dopotutto rispettano anche le condizioni per essere track: - sono strade che non collegano località o frazioni [...] in questo caso track va benissimo Mi sembra importante comunque differenziarle dalle asfaltate, per questo c'e` il tag surface: sta semmai ai render controllare la sua presenza (e magari renderizzare le unclassified non asfaltate con i bordi tratteggiati, o qualcosa del genere, ma distinto dalle track) -- Elena ``of Valhalla'' homepage: http://www.trueelena.org email: elena.valha...@gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
