Re: [talk-ph] Micro Mapping Party in Ortigas-Mandaluyong on May 22
Sana humabol: Slice 1: http://paperwalking-uploads.s3.amazonaws.com/prints/fwhmqxzx/walking-paper-fwhmqxzx.pdf Slice 2: http://paperwalking-uploads.s3.amazonaws.com/prints/xq6z28n4/walking-paper-xq6z28n4.pdf Slice 2: http://paperwalking-uploads.s3.amazonaws.com/prints/5t3l6hcf/walking-paper-5t3l6hcf.pdf Slice 4: http://paperwalking-uploads.s3.amazonaws.com/prints/sn5b35mg/walking-paper-sn5b35mg.pdf Slice 4: http://paperwalking-uploads.s3.amazonaws.com/prints/m8ttl2d3/walking-paper-m8ttl2d3.pdf Slice 5: http://paperwalking-uploads.s3.amazonaws.com/prints/ff7cdpq4/walking-paper-ff7cdpq4.pdf Slice 5: http://paperwalking-uploads.s3.amazonaws.com/prints/m5czs849/walking-paper-m5czs849.pdf Slice 5: http://paperwalking-uploads.s3.amazonaws.com/prints/wpsbwxnf/walking-paper-wpsbwxnf.pdf No slice 3 since it's quite blank. On Fri, May 21, 2010 at 8:14 AM, maning sambale emmanuel.samb...@gmail.comwrote: On Fri, May 21, 2010 at 12:02 AM, Eugene Alvin Villar sea...@gmail.com wrote: So final logistics needed: 1. Walking Papers printout of the slices - who can volunteer to do this? I can print this, just give me the pdf links. No time to navigate around walkingpapers site today. 2. The OSM banner - maning, is this still with you? Yep, I'll bring the banner including 2 extra gps (gt-31 and garmin etrex) 3. Choice of an afternoon meet-up venue - I'm thinking of a coffeehouse with power outlets and free Wi-Fi. Either Megamall or Galleria since these malls have free Wi-Fi. I would suggest is Starbucks Megastrip http://www.ka-fi.com/place/starbucks__megamall_megastrip/. Any other options? See you all on Saturday! On Tue, May 18, 2010 at 11:57 AM, Eugene Alvin Villar sea...@gmail.com wrote: The link to Facebook is obviously wrong. It should be: http://www.facebook.com/event.php?eid=121402554549978 If you have a Facebook account, please RSVP if you can (even a decline would be useful). :-) The cake slices are also set: http://wiki.openstreetmap.org/wiki/Ortigas-Mandaluyong_Mapping_Party#Cake_slices On Mon, May 17, 2010 at 9:08 PM, Eugene Alvin Villar sea...@gmail.com wrote: Here are two pages: 1. The Facebook event page (RSVP there if you have an account): http://wiki.openstreetmap.org/wiki/Ortigas-Mandaluyong_Mapping_Party 2. The OSM Wiki announcement page (still under construction): http://wiki.openstreetmap.org/wiki/Ortigas-Mandaluyong_Mapping_Party On Sat, May 15, 2010 at 9:34 PM, ianlopez ian_lopez_1...@yahoo.com wrote: I've suggested other areas that are close enough but not too far from the Ortigas area 1. EDSA-Pioneer-Boni Avenue intersection: http://sautter.com/map/?zoom=17lat=14.57255lon=121.0472layers=0BTF There are new developments in the area, specifically in the Pioneer side (Robinsons Cybergate, Light Residences, Pioneer Woodlands) 2. Area between Boni-Pionner intersection and Kapitolyo: http://sautter.com/map/?zoom=17lat=14.57297lon=121.05339layers=0BTF The streets are complete, but it lacks POI's, buildings and landuse. Maybe one of us should hand out OSM fliers to passers-by [if they're interested] ( http://wiki.openstreetmap.org/wiki/File:OSM-PH_Flyer_2010-03-19.pdf ) Tony Montana: Me, I want what's coming to me. Manny Ribera: Oh, well what's coming to you? Tony Montana: The world, chico, and everything in it. - http://ianlopez1115.wordpress.com/ --- On Sat, 5/15/10, Eugene Alvin Villar sea...@gmail.com wrote: From: Eugene Alvin Villar sea...@gmail.com Subject: [talk-ph] Micro Mapping Party in Ortigas-Mandaluyong on May 22 To: OSM talk-ph@openstreetmap.org Date: Saturday, May 15, 2010, 10:22 AM Hi guys, I really don't think we could push through with the Corregidor Mapping Party. Planning was mostly nonexistent and I don't think many people are willing to spend a large amount of money for the ferry trip and the possible overnight stay in the hotel on Corregidor. Let's postpone that island for a while. In the meantime, I suggest we tackle parts of Metro Manila that are still incomplete: 1. Mandaluyong-Shaw area: http://sautter.com/map/?zoom=17lat=14.58246lon=121.04721layers=B0TF This area of Mandaluyong is still missing a lot of streets because they are covered by clouds in the Yahoo satellite imagery. 2. Ortigas CBD: http://sautter.com/map/?zoom=17lat=14.58448lon=121.05964layers=B0TF In contrast to the Makati CBD, Ortigas is still pretty blank in its building coverage. 3. Metrowalk-Ortigas Home Depot: http://sautter.com/map/?zoom=17lat=14.58647lon=121.06578layers=B0TF Yahoo's satellite imagery in this area predates the large retail construction here so it would be nice if we can map this new development. One nice thing about this is that these three areas are near each other and since this is Ortigas, meeting up would be easier. And after the on-the-field surveying, let's
[Talk-si] Nadzor kakovosti
Zdravo, zanima me kako je z nadzorom nad kakovostjo podatkov - če Slovenska OSM skupina uporablja kako orodje, ki bi to olajšalo? Katera se uporabljajo, katera mislite, da bi bilo dobro, če bi se? Če namreč malo nekoordinirano zajemamo sledi, se utegne zgodit, da bodo podatki nekvalitetni oz. da bo treba več truda, kot bi to želeli. Pripravljen sem tudi kaj postavit ali pa se pogovarjat z že obstoječimi sistemi, ki jih nekateri ponujajo, kot je npr. tagwatch. Lp, Gašper ___ Talk-si mailing list Talk-si@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-si
Re: [OSM-legal-talk] some questions about Produced Works under the ODbL
1. Is it clear that a map tile is an image within the definition of a Produced Work--a work (such as an image...) resulting from using the whole or a Substantial part of the Contents?If not, what is the most typical example of a Produced Work in the map context? Consider a produced work of something that cannot be reproduced because disassembling is not possible. Take a cake for example (kitchen wise, just for understanding the concept). You cannot produce a another cake from the first cake or alter it because you cannot disassemble it to the original ingredients since the ingredients have been transformed in a chemical process. The cake would be a Produced Work. If you take a car it can always be disassembled to its individual pieces and be rebuild. The car would not be a Produced Work. Also consider the intention behind the concept: The idea is that if someone improves the original source then this improvement should go back to the community. This means if you improve one of the ingredients then this improvement should become part of the community. Any Produced Work will not benefit the community (for the next Derived or Produced Work) and therefore does not need to go back to the community. Regards, Oliver -- View this message in context: http://gis.638310.n2.nabble.com/OSM-legal-talk-some-questions-about-Produced-Works-under-the-ODbL-tp5080305p5083981.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] some questions about Produced Works under the ODbL
What you're saying, basically, is that making a cake loses the (or some) properties of the ingredients, thus a produced work; making a car doesn't, thus not produced. (Of course making a car also entails irreversible actions but let's ignore that for the moment.) Transferred back to the map database, your argument would be that anything which does not allow one to go back to the data is a produced work. You make a distinction between the result can be (a) fully, (b) partly or (c) not at all be traced back. I think the key question is if you can update your work based on updated OSM data. This would be the case for (a) and (b) and therefore not be a Produced Work rather a Derived Work. I was just making it black or white. My cake was considered to fall into category (c) - not being traceable - and therefore a Produced Work. I think the updatability is key when distinguishing between Derived and Produced Work. Interesting question: If you did shred the data, would you be allowed to publicly display your Atlas afterwards? To my understanding and in line with my concept above it could be treated as produced work that is based on non-modified data. Otherwise any source data of a produced work would have to be made available and I think this is not the intention. Regards, Oliver -- View this message in context: http://gis.638310.n2.nabble.com/OSM-legal-talk-some-questions-about-Produced-Works-under-the-ODbL-tp5080305p5084194.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] New OSM contributor licensing under ODbL and CC-BY-SA started today
Mike Collinson m...@... writes: - When enough contributors have agreed, we cut over to licensing the current database under ODbL, (And a static snapshot of the database is also made forever under CC-BY-SA). If for some reason this event never happens, the fail safe is that licensing of all contributions under CC-BY-SA simply continues. Surely this is two separate steps: - begin offering a licence to the whole database under ODbL, - stop offering a licence under CC-BY-SA. They might happen at the same time but they don't have to. -- Ed Avis e...@waniasset.com ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] New OSM contributor licensing under ODbL and CC-BY-SA started today
On Fri, May 21, 2010 at 1:03 PM, Ed Avis e...@waniasset.com wrote: Mike Collinson m...@... writes: - When enough contributors have agreed, we cut over to licensing the current database under ODbL, (And a static snapshot of the database is also made forever under CC-BY-SA). If for some reason this event never happens, the fail safe is that licensing of all contributions under CC-BY-SA simply continues. Surely this is two separate steps: - begin offering a licence to the whole database under ODbL, - stop offering a licence under CC-BY-SA. They might happen at the same time but they don't have to. I expect that the last ccbysa database will continue to be available as a planet file, just as older ccbysa planet files are available now. I suspect that proceeding with two active databases would be impractical, just as we don't support active editing on the 2006-01-01 planet file version of the database. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Editing Derived Database Extracts and ODbL
On 21 May 2010 14:47, Oliver (skobbler) osm.oliver.ku...@gmx.de wrote: Share-Alike: If you publicly use any adapted version of this database, or works produced from an adapted database, you must also offer that adapted database under the ODbL. (I am trusting/hoping the human readable terms match the legalese.) So...my question is: how _useful_ does the derived database have to be? Does the ODbL require any usefulness to diffs, or only that the available database materials exactly match any temporary database used to create a produced work? The first question is if the adapted database needs be offered actively or passively (meaning on demand). I would assume that it only needs to be offered on demand when I try to assume the concept behind it: The intention is that if you add something to the source that is valuable for the community then the community should have the chance to integrate the addition also into the source. This will only happen if someone of the community is prepared to take the effort, which would require it to be of significant value. Unfortunately the community won't be able to integrate any substantial amount of data unless the author also accepted the Contributor Terms which they don't have to do. But, what if I do something really rude like remove all of the node IDs? The derived database might have some very useful properties, but it will be a truly royal PITA to apply back to OSM. If you keep a relation to the node IDs then these must be handed out as well. If you have deleted the node IDs then it probably becomes a Produced Work but as long as it remains in a state where you can update the temporary database with more recent OSM data then this requires a link from the OSM IDs to your elements in the temporary database. The key question here is if the temporary database keeps a link to the OSM database and then this link must be provided as well. I don't think this distinction of whether you can keep your database updated or not is anywhere in the ODbL. If it was the way you explain it, it would be really easy to make a dataset containing all the useful data and not bound by the limitations a Derived Work bears. You could even generate a new Produced Work automatically every time something changes in OpenStreetMap and never have to release your additions. Cheers ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Editing Derived Database Extracts and ODbL
Hi, I don't think this distinction of whether you can keep your database updated or not is anywhere in the ODbL. If it was the way you explain it, it would be really easy to make a dataset containing all the useful data and not bound by the limitations a Derived Work bears. You could even generate a new Produced Work automatically every time something changes in OpenStreetMap and never have to release your additions. The interesting point is that this behaviour exactly applies to a jpg-file that is derived from the database and which is doubtlessly classified as Produced Work: with every update of the osm-data you can create a new jpg-file and it always remains a Produced Work. I see only two points that characterize the jpg-file as special: you cannot disasseble it and you cannot trace back to osm database elements automatically. Regards, Oliver ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Little religious man made objects : crosses and shrines
Christian Rogel wrote: In Feb. 08, a German User initiated two proposals about wayside religious man made objects . The discussion is moving at slow pace and no voting is previsible. http://wiki.openstreetmap.org/wiki/Proposed_features/wayside_cross http://wiki.openstreetmap.org/wiki/Proposed_features/wayside_shrine Both were adopted without a vote. The pages are obsolete since we do have http://wiki.openstreetmap.org/wiki/Tag:historic%3Dwayside_cross http://wiki.openstreetmap.org/wiki/Tag:historic%3Dwayside_shrine I think the original 'voting' was under the Key:historic tag, and was to do with the differences between these, memorial and monument -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Any way to recover these Potlatch changes?
Nathan Edgars II schrieb: A couple hours ago I made a bunch of edits in Potlatch and saved. While editing the loading from the API was intermittent, and this continued during the saving. I canceled the save and tried again, and now it refuses to save or load anything. I also can't access any pages on openstreetmap.org. However, if I load a different browser, I can load and save just fine. Presumably restarting the browser would fix the problem, but then I'd lose the unsaved changes. Is there anything I can do to save them? If you need time support, better go to the irc channel :) Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] place=isolated_dwelling approved - adding to mapfeatures
On Fri, May 21, 2010 at 1:16 AM, Aun Johnsen li...@gimnechiske.org wrote: I took the freedom to remove the mark of deprecated on place=farm and wrote a page with an easy to understand (I hope) definition of what a farm can be different from isolated dwelling http://wiki.openstreetmap.org/wiki/Tag:place%3Dfarm But that's even worst. It says now: A farm can be a part of a place Then simply, don't use the key 'place' but a subset of the place=isolated_dwelling I know how difficult it is to deprecate a tag. In OSM it is almost impossible. That's why people are just piling up new tags without cleaning up the previous similar ones. I don't give more than 3 monthes until a hugh thread comes on this list asking a clarification between the different place values. For instance, I wish good luck to the guy who will update the page Key:place and write: place=farm In some countries the official type of a residential area smaller than a hamlet (Germany: Gehöft http://en.wikipedia.org/wiki/de:Geh%C3%B6ft). place=isolated_dwelling In some countries the official type of a residential area smaller than a hamlet (Germany: nicht ein Gehöfthttp://en.wikipedia.org/wiki/de:Geh%C3%B6ft). It's really sad that we start mixing keys 'building' and 'place' just because they have a locality name. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] place=isolated_dwelling approved - adding to mapfeatures
Hi, Pieren wrote: place=farm In some countries the official type of a residential area smaller than a hamlet (Germany: Gehöft http://en.wikipedia.org/wiki/de:Geh%C3%B6ft). place=isolated_dwelling In some countries the official type of a residential area smaller than a hamlet (Germany: nicht ein Gehöft http://en.wikipedia.org/wiki/de:Geh%C3%B6ft). I don't like the in some countries stuff. OSM is not organised by countries. I suggest: place=farm - use this for residential areas smaller than a hamlet, unless you think that place=isolated_dwelling is more appropriate place=isolated_dwelling - use this for residential areas smaller than a hamlet, unless you think that place=farm is more appropriate You may also use landuse=residential for residential areas or landuse=farmyard for farm yards. If someone lives on the farm, either tag place=farm and landuse=residential, or use place=isolated_dwelling and landuse=farmyard. I'm not entirely serious about this. But a little. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Navigation Debug Map Style Available
Hi Guys, Happy Friday. The navigation debug map style we've been working on at CloudMade is now available for browsing, and use as a tile source: http://cartography.sandbox.cloudmade.com/navdebug/?lat=51.51379lng=-0.106988zoom=15 Features Shows: * Lane numbers * Speed limits * Turn restrictions - no turns and one direction only * One ways * U-Turns * Roundabouts Grab a PDF legend from here: http://vagafonkin.sandbox.cloudmade.com/navdebug/legend.pdf Details: * Updated once a day * Tiles are rendered on the fly. The more you use, the more we cache :-) Future: * Add more nav features * Integration into Mapzen * Faster updates *... anything else? -- Nick Black n...@cloudmade.com twitter.com/nick_b ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] place=isolated_dwelling approved - adding to mapfeatures
On Fri, 21 May 2010, Frederik Ramm wrote: Hi, Pieren wrote: place=farm In some countries the official type of a residential area smaller than a hamlet (Germany: Gehöft http://en.wikipedia.org/wiki/de:Geh%C3%B6ft). place=isolated_dwelling In some countries the official type of a residential area smaller than a hamlet (Germany: nicht ein Gehöft http://en.wikipedia.org/wiki/de:Geh%C3%B6ft). I don't like the in some countries stuff. OSM is not organised by countries. I suggest: place=farm - use this for residential areas smaller than a hamlet, unless you think that place=isolated_dwelling is more appropriate place=isolated_dwelling - use this for residential areas smaller than a hamlet, unless you think that place=farm is more appropriate You may also use landuse=residential for residential areas or landuse=farmyard for farm yards. If someone lives on the farm, either tag place=farm and landuse=residential, or use place=isolated_dwelling and landuse=farmyard. I'm not entirely serious about this. But a little. Bye Frederik This started as a deprecate farmyes/no thread because now solated_dwelling will now replace farm these concepts are neither mutually exclusive nor complementary they overlap neither one can be used instead of the other what about the isolated dwelling of the lighthouse keeper? what about the farm that is not isolated? I don't find isolated_dwelling useful at all in my view of my country I accept that others find it useful in their view of their country. We may not be organised by country but we can't all fit into each others country view. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Navigation Debug Map Style Available
* Lane numbers * Speed limits * Turn restrictions - no turns and one direction only * One ways * U-Turns * Roundabouts Great tool! This is the first one I've seen with 'mph' Speed Limit summaries. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] place=isolated_dwelling approved - adding to mapfeatures
2010/5/21 Frederik Ramm frede...@remote.org: . place=farm - use this for residential areas smaller than a hamlet, unless you think that place=isolated_dwelling is more appropriate farm is usage of the place. place=* tag is definitely more about size of settlement than usage of it. place=isolated_dwelling - use this for residential areas smaller than a hamlet, unless you think that place=farm is more appropriate But why? Why so big exclusivity about farm? Again, farm is what is located at this place, not place itself. Cheers, Peter. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] place=isolated_dwelling approved - adding to mapfeatures
2010/5/21 Aun Johnsen li...@gimnechiske.org: I took the freedom to remove the mark of deprecated on place=farm and wrote a page with an easy to understand (I hope) definition of what a farm can be different from isolated dwelling http://wiki.openstreetmap.org/wiki/Tag:place%3Dfarm OK, I made some further changes, please check if this is OK with you. Btw. (asuming that you are Skippern): you wrote that Gehöft is an official term for settlements smaller than hamlets in Germany. Where did you get this information from? IMHO the right generic term (on the same level as hamlet or village) for this is indeed Einzelsiedlung as I wrote there. Am I supposing right, that this information is only based on Wikipedia:de/Weiler ? cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Garmin Maps
On Thu, May 20, 2010 at 9:34 PM, SteveC st...@asklater.com wrote: Why do you take responsibility for postal losses? That seems super bad luck. You're running a business right not a socialist theocracy. Just put a note on the checkout that says uninsured postal delivery: £4 recorded, insured delivery: £10 I can tell you haven't run an online shop yet :-) The insurance and recording is irrelevant to the customer, since it's me who is insured and/or making the claim - so it makes no sense to offer the customer the choice. I have two choices, either to charge considerably more for recorded post, which adds hassle to both me and my customers, or go with the default postage and hope that both the mail company delivers and the customers don't falsely claim non-receipt. I say hope but it's actually carefully balanced - the extra cost-per-sale (and subsequent reduction in sales) is weighed against the occasional loss but increased revenue from lower prices. The tipping point depends largely on the margin per sale (the bigger the margin, the less of a problem re-sending becomes), so I handle some products differently to others. Good to know that you are confusing great customer services and careful economics with misplaced religious belief systems! Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] place=isolated_dwelling approved - adding to mapfeatures
On Fri, May 21, 2010 at 3:06 PM, Peteris Krisjanis pec...@gmail.com wrote: farm is usage of the place. place=* tag is definitely more about size of settlement than usage of it. Exactly. That's why I suggest (and some others) to deprecate place=farm. Otherwise, we will see in the futur place=restaurant, place=manufactory, place=watermill, etc as soon as it is named and not part of a bigger place (isolated). No reasons to stop this mess where in the past the place hierarchy was quite clear: city town village hamlet locality and suburb as part of a city or town Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] place=isolated_dwelling approved - adding to mapfeatures
2010/5/21 Pieren pier...@gmail.com: No reasons to stop this mess where in the past the place hierarchy was quite clear: city town village hamlet locality this is actually not clear, because locality was long ago (or has ever been) defined as uninhabited place, regardless the size of the feature (so it falls in the category island and other non-settlement-place-tags). and suburb as part of a city or town that's the second part being not clear. If suburb (horrible word for central places) is part of city or town, why not having also parts of hamlets tagged explicity if they have their own name? Another problem with suburb I see is that there is no distinction for official (read administrative) places from ones that are only subparts of administrative entities but with their own name. I would like to be able, given the hypothetical situation that all data is entered completely and correctly, to e.g. calculate the population of Germany by summarizing all population-values of certain place-tags (isolated_dwelling, hamlet, village, town, city) and disregarding the rest (like suburb), which should already be included in the ones mentioned above. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] some questions about Produced Works under the ODbL
You can certainly have a derived database that is not updateable (e.g. simply drop all IDs). That is true but you can have at least the negative conclusion: if it is updatable then it is no Produced Work. I initially thought it would take out most of the value but it is not (completely) true. if someone creates a snapshot of the database, cuts off all IDs and builds a branch of OSM map then it is still highly valuable for a map producer (while most users are interested OpenStreetMap data that are updated). Consequently this means that if you put layer (not an image) of e.g. outlets like McDonalds on the map (and fulfill the criteria of substantiability - meaning more than 100) than you have to make these outlet database available. So far, I was assuming that a layer of POIs on top of the map is a Produced Work but it is not as soon as it becomes significant (volume wise). This also means that commercial POI providers cannot show POIs on top of the OSM map without their data falling under the Share-A-Like license. if you Publicly Use a Produced Work, You must include a notice associated with the Produced Work reasonably calculated to make any Person that uses, views, accesses, interacts with, or is otherwise exposed to the Produced Work aware that Content was obtained from the Database, Derivative Database, or the Database as part of a Collective Database, and that it is available under this License. This sounds as if you would have to make [everyone] aware that [the database] is available under this license - but in my hypothetical situation the database does not exist any more. I read it as you need to mention the origin of the Produced Work with its underlying license rather than providing the database. Any derived database needs only to be made available if it is made public either direct or indirect (through an application) to my understanding. Regards, Oliver -- View this message in context: http://gis.638310.n2.nabble.com/OSM-legal-talk-some-questions-about-Produced-Works-under-the-ODbL-tp5080305p5084828.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-talk] Google Hiring 300 Temps to Fix Map Errors
http://www.techflash.com/seattle/2010/05/google_hiring_300_temp_workers_in_kirkland_to_pinpoint_bugs_in_google_maps.html Anyone care to come up with a press release that says something like OpenStreetMap volunteers, numbering in the 10s of thousands, fixing a free map for free. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Garmin Maps
interesting: http://reviews.ebay.co.uk/When-Items-Get-Lost-In-The-Post_W0QQugidZ103212591 out of interest, does RM actually compensate you then? On May 21, 2010, at 7:07 AM, Andy Allan wrote: On Thu, May 20, 2010 at 9:34 PM, SteveC st...@asklater.com wrote: Why do you take responsibility for postal losses? That seems super bad luck. You're running a business right not a socialist theocracy. Just put a note on the checkout that says uninsured postal delivery: £4 recorded, insured delivery: £10 I can tell you haven't run an online shop yet :-) The insurance and recording is irrelevant to the customer, since it's me who is insured and/or making the claim - so it makes no sense to offer the customer the choice. I have two choices, either to charge considerably more for recorded post, which adds hassle to both me and my customers, or go with the default postage and hope that both the mail company delivers and the customers don't falsely claim non-receipt. I say hope but it's actually carefully balanced - the extra cost-per-sale (and subsequent reduction in sales) is weighed against the occasional loss but increased revenue from lower prices. The tipping point depends largely on the margin per sale (the bigger the margin, the less of a problem re-sending becomes), so I handle some products differently to others. Good to know that you are confusing great customer services and careful economics with misplaced religious belief systems! Cheers, Andy Yours c. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google Hiring 300 Temps to Fix Map Errors
OSM: using 10,000 people to do what Google does with 300. ;) On Fri, May 21, 2010 at 11:50 AM, Ian Dees ian.d...@gmail.com wrote: http://www.techflash.com/seattle/2010/05/google_hiring_300_temp_workers_in_kirkland_to_pinpoint_bugs_in_google_maps.html Anyone care to come up with a press release that says something like OpenStreetMap volunteers, numbering in the 10s of thousands, fixing a free map for free. ___ 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] Google Hiring 300 Temps to Fix Map Errors
Anthony wrote: OSM: using 10,000 people to do what Google does with 300. ;) Can we make a Best quotes of OSM on the wiki? :D Maarten On Fri, May 21, 2010 at 11:50 AM, Ian Dees ian.d...@gmail.com mailto:ian.d...@gmail.com wrote: http://www.techflash.com/seattle/2010/05/google_hiring_300_temp_workers_in_kirkland_to_pinpoint_bugs_in_google_maps.html Anyone care to come up with a press release that says something like OpenStreetMap volunteers, numbering in the 10s of thousands, fixing a free map for free. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Any way to recover these Potlatch changes?
On Fri, May 21, 2010 at 3:36 AM, Peter Körner osm-li...@mazdermind.de wrote: Nathan Edgars II schrieb: A couple hours ago I made a bunch of edits in Potlatch and saved. While editing the loading from the API was intermittent, and this continued during the saving. I canceled the save and tried again, and now it refuses to save or load anything. I also can't access any pages on openstreetmap.org. However, if I load a different browser, I can load and save just fine. Presumably restarting the browser would fix the problem, but then I'd lose the unsaved changes. Is there anything I can do to save them? If you need time support, better go to the irc channel :) Yeah, really useful: KomzpaNE2: throw away potlatch and use josm (or vim) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Garmin Maps
On 22 May 2010 01:55, SteveC st...@asklater.com wrote: out of interest, does RM actually compensate you then? I don't know about RM in the UK, but Auspost in Australia hates paying up on insurance claims and they will usually track it down and find it as a result :) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google Hiring 300 Temps to Fix Map Errors
On 22 May 2010 01:50, Ian Dees ian.d...@gmail.com wrote: http://www.techflash.com/seattle/2010/05/google_hiring_300_temp_workers_in_kirkland_to_pinpoint_bugs_in_google_maps.html Anyone care to come up with a press release that says something like OpenStreetMap volunteers, numbering in the 10s of thousands, fixing a free map for free. Number aren't the best angle imho, wouldn't it be better to point out the fact how OSM is working much better at crowd sourcing because people can take their data back out of the system, rather than working for free for google? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Geowanking] closedstreetmap.org
On 21 May 2010 00:34, Peter Batty peter.ba...@gmail.com wrote: And perhaps also private organizations that will take your data but not let you have it back :) ? Sent from my iPhone ^^^ oh, the irony ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] place=isolated_dwelling approved - adding to mapfeatures
An old definition of places in Norway (do not know if it actually legal definition anymore) was as follow Land (nation) - herred (region) - amt (state) - fogd (church area) - len (munincipality) - by (city or town) / grend (hamlet) - gard (farm) Some of these have been weakened with time, so that herred have been removed (also changed meaning a few times in history), amt are renamed fylke and are aout to be removed as they are taking away the administrative responsebilities of it, len have been renamed kommune, and by is not longer considered a subdevision of kommune, just having the same status (in a way), grend is a natural way to divide a rural munincipal, and gard is still part of the grend. Gard is not necessary an active farm, many of them just used to be farm, but now are a residential place for one to three famillies, surrounded by the farmland that used to belong to that farm. They are not isolated dwellings, they are just the suburbs of a hamlet Maybe place=farm is not the right tag for a gard (which translates farm even if there are no farming activities there), but it should be tagged different than vær, which is a small isolated place (which probably would be tagged place=village or might be considered place=isolated_dwelling) - the last one is a densely built small place, generally a fishing community, cramped around a safe port. In most cases access to only a little cultivated land, so that the population in general cannot combine farming and fishing. Many of these are so isolated that there exists no cars there. A[] ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google Hiring 300 Temps to Fix Map Errors
On Sat, May 22, 2010 at 1:50 AM, Ian Dees ian.d...@gmail.com wrote: http://www.techflash.com/seattle/2010/05/google_hiring_300_temp_workers_in_kirkland_to_pinpoint_bugs_in_google_maps.html Anyone care to come up with a press release that says something like OpenStreetMap volunteers, numbering in the 10s of thousands, fixing a free map for free. I once had a job like that, working on the main search engine. Google set up the infrastructure, then outsourced the actual hiring and paying through a temp agency. You sit at home, rating search results one at a time, for like $30 an hour. Trouble was, I found I could never do more than about 2 hours a day without going out of my mind. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Navigation Debug Map Style Available
On Fri, May 21, 2010 at 8:36 PM, Nick Black nickbla...@gmail.com wrote: * Speed limits Not quite sure what to make of what I'm seeing - trunk roads with an estimated speed limit of 85kph (there's no such thing as a _5kph limit in Australia). Is this in scope for the comments you're seeking? *... anything else? Cyclelanes. I assume the purpose of this map is to sure recorded information which is not rendered in mapnik, to elevate its visibility. So, cycleway=lane would fall into that category. For navigation, how about surfaces - people diligently record this information but it's hardly ever used. Particularly surface=paved, unpaved, dirt, cobblestone, etc... Access tags? Bus/tram/train route numbers? Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] scuba dive sites
On searching, I have seen several pages and proposals in the wiki for scuba diving sites and for dive shops. I am currently tagging up the island of Utila, Honduras, which is well known for its diving. What can I use as a basic tag type for these two things (a dive location and a dive shop which sells courses, provides equipment etc)? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] scuba dive sites
On 22 May 2010 14:40, Joe Richards joefis...@yahoo.com wrote: On searching, I have seen several pages and proposals in the wiki for scuba diving sites and for dive shops. I am currently tagging up the island of Utila, Honduras, which is well known for its diving. What can I use as a basic tag type for these two things (a dive location and a dive shop which sells courses, provides equipment etc)? I've seen some dive sites tagged as place=locality ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Navigation Debug Map Style Available
On 22 May 2010 14:32, Steve Bennett stevag...@gmail.com wrote: For navigation, how about surfaces - people diligently record this information but it's hardly ever used. Particularly surface=paved, unpaved, dirt, cobblestone, etc... Access tags? Bus/tram/train route I'd love to see unpaved tagged as dash lines, similar to most maps in Australia, as for surface=paved this can be assumed 99% of the time, how many residential roads or motorways have you seen unpaved? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[talk-au] Fwd: [OSM-talk] Navigation Debug Map Style Available
-- Forwarded message -- From: Nick Black nickbla...@gmail.com Date: 21 May 2010 20:36 Subject: [OSM-talk] Navigation Debug Map Style Available To: osm t...@openstreetmap.org Cc: Pavel Tsekhotsky ptsekhot...@cogniance.com, Vladimir Agafonkin vagafon...@cloudmade.com Hi Guys, Happy Friday. The navigation debug map style we've been working on at CloudMade is now available for browsing, and use as a tile source: http://cartography.sandbox.cloudmade.com/navdebug/?lat=51.51379lng=-0.106988zoom=15 Features Shows: * Lane numbers * Speed limits * Turn restrictions - no turns and one direction only * One ways * U-Turns * Roundabouts Grab a PDF legend from here: http://vagafonkin.sandbox.cloudmade.com/navdebug/legend.pdf Details: * Updated once a day * Tiles are rendered on the fly. The more you use, the more we cache :-) Future: * Add more nav features * Integration into Mapzen * Faster updates *... anything else? -- Nick Black n...@cloudmade.com twitter.com/nick_b ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] General Observations.
On Thu, May 20, 2010 at 12:13 PM, Ross Scanlon i...@4x4falcon.com wrote: If the info in the database is Alpha St then what's to say the it is not Alpha Saint or Alpha Strip or Alpha Street and so you end up with lot's of extraneous results. By entering the full type of street, road, etc it's then just a matter of having an appropriate abbreviation look up table to convert from before searching going the other way is more difficult. So entering Alpha Street will return the correct info but likewise so will Alpha St. I honestly think it's a totally arbitrary decision whether we do the interpretation of St - Street (and vice versa) at the time we record it, or at the time we generate a map. But we've made the decision (we expand them at the time we record it), so let's just stick with it and be consistent. We should also make our tools as flexible as possible, to allow people to search both abbreviated and unabbreviated forms. Even to the extent that Saint Kilda should work, even though it's never ever spelt out like that. (There never was a saint by that name...) Steve ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] General Observations.
On 22 May 2010 14:36, Steve Bennett stevag...@gmail.com wrote: stick with it and be consistent. We should also make our tools as flexible as possible, to allow people to search both abbreviated and unabbreviated forms. Even to the extent that Saint Kilda should work, even though it's never ever spelt out like that. (There never was a saint by that name...) Is there any direct OSM tools that doesn't have this feature already? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[Talk-br] Relatório Semanal: 21/05/2010
*Status dos Projetos OSM-br* * B250C - Brasil 250 Cidades* Página do Projeto: http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Brasil_250_Cidades *2a. fase* Conectividade em *73,65%* *(+1,70%)* Grid Atualizado (html): http://mapaslivres.org/cidades-distancias.html (13 Mb) Grid Atualizado (zip): http://mapaslivres.org/cidades-distancias.zip (2 Mb) *JOSM - Tradução ao português* Página do Projeto: https://translations.launchpad.net/josm/trunk/+pots/josm Indicador: Percentual de strings traduzidas em *70.15% **(+0.03%)* Tradução do Texto de Notícias do JOSM:http://josm.openstreetmap.de/wiki/StartupPageSource *Merkaator - Tradução ao português* Página do Projeto: https://translations.launchpad.net/merkaartor Indicador: Percentual de strings traduzidas em *89.78% **(+22,43%)* *Site osm.org - Tradução ao português * Página do Projeto: http://translatewiki.net/wiki/Translating:OpenStreetMap/stats/trunk/site Indicador: String Traduzidas em *100%* *Potlach* - *Tradução ao português* Página do Projeto: http://translatewiki.net/wiki/Translating:OpenStreetMap/stats/trunk/potlatch Indicador: String Traduzidas em *100%* ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Aspectos a serem mapeados numa rodovia
Olá, pessoal Amanhã viajarei para João Pessoa de carro (de Natal, para quem não sabe onde moro). Eu queria algumas sugestões de coisas importantes a serem mapeadas. Já pensei em algumas, mas devo estar esquecendo de várias: - A rodovia --- Nº de faixas --- Retornos --- Entradas para outras estradas --- Pontes --- Obras - Postos de gasolina. - Cidade e povoados por onde a estrada passa (se bem que os dados do IBGE já cobrem quase tudo) - Pontos turísticos Como não vou dirigir, dá pra anotar alguma coisas enquanto passamos por elas. Consegui conectar o GPS ao netbook e estarei vendo o mapa e o lugar onde estamos durante todo o caminho (usando o TangoGPS, no Linux). Além disso, vou tirar fotos e sincronizá-las com o GPS depois. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Aspectos a serem mapeados numa rodovia
Ah, Esqueci de um detalhe importante. Pontos onde a rodovia duplica e desduplica, além dos limites de velocidade envolvidos. 2010/5/21 Claudomiro Nascimento Junior claudom...@claudomiro.com: Essa lista que vc falou é bem completa. Implica em parar várias vezes no percurso pra entrada de dados - vc tem um MP3/gravador de voz digital? ele pode agilizar a coleta de dados tb De qualquer maneira, não esqueça o aspecto da segurança, heim? Nada de parar fora do acostamento ou tirar a atenção da estrada... bom mapeamento. 2010/5/21 Bráulio Bezerra da Silva brauliobeze...@gmail.com: Olá, pessoal Amanhã viajarei para João Pessoa de carro (de Natal, para quem não sabe onde moro). Eu queria algumas sugestões de coisas importantes a serem mapeadas. Já pensei em algumas, mas devo estar esquecendo de várias: - A rodovia --- Nº de faixas --- Retornos --- Entradas para outras estradas --- Pontes --- Obras - Postos de gasolina. - Cidade e povoados por onde a estrada passa (se bem que os dados do IBGE já cobrem quase tudo) - Pontos turísticos Como não vou dirigir, dá pra anotar alguma coisas enquanto passamos por elas. Consegui conectar o GPS ao netbook e estarei vendo o mapa e o lugar onde estamos durante todo o caminho (usando o TangoGPS, no Linux). Além disso, vou tirar fotos e sincronizá-las com o GPS depois. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Aspectos a serem mapeados numa rodovia
2010/5/21 Bráulio Bezerra da Silva brauliobeze...@gmail.com: Olá, pessoal Amanhã viajarei para João Pessoa de carro (de Natal, para quem não sabe onde moro). Eu queria algumas sugestões de coisas importantes a serem mapeadas. Já pensei em algumas, mas devo estar esquecendo de várias: - A rodovia --- Nº de faixas --- Retornos --- Entradas para outras estradas --- Pontes --- Obras - Postos de gasolina. - Cidade e povoados por onde a estrada passa (se bem que os dados do IBGE já cobrem quase tudo) - Pontos turísticos Bom, tem mais algumas coisas pra lembrar se você quer ter uma mapa boa: - Velocidade máxima - Pedágios - Borracharias - Radares - Nomes: aqui em SP muda frequentemente, SP-215 tem uns 5 nomes diferente - Sair e entrar em todas as saídas, atravessar todos os pontes etc com GPS Boa sorte! :-) -- Johan Dahlin ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Aspectos a serem mapeados numa rodovia
Os trechos onde a rodovia tem postes de iluminação e onde não tem, para usar a tag lit=yes|no. Se é asfalto o tempo todo ou se tem partes de terra/pedras, para usar a tag surface=asphalt|cobblestone|dirt Divirta-se :) []s -- Arlindo Pereira Analista de Segurança Grupo Clavis Segurança da Informação http://www.clavis.com.br +55 21 2210-6061 +55 21 2561-0867 Em 21 de maio de 2010 13:45, Johan Dahlin jo...@gnome.org escreveu: 2010/5/21 Bráulio Bezerra da Silva brauliobeze...@gmail.com: Olá, pessoal Amanhã viajarei para João Pessoa de carro (de Natal, para quem não sabe onde moro). Eu queria algumas sugestões de coisas importantes a serem mapeadas. Já pensei em algumas, mas devo estar esquecendo de várias: - A rodovia --- Nº de faixas --- Retornos --- Entradas para outras estradas --- Pontes --- Obras - Postos de gasolina. - Cidade e povoados por onde a estrada passa (se bem que os dados do IBGE já cobrem quase tudo) - Pontos turísticos Bom, tem mais algumas coisas pra lembrar se você quer ter uma mapa boa: - Velocidade máxima - Pedágios - Borracharias - Radares - Nomes: aqui em SP muda frequentemente, SP-215 tem uns 5 nomes diferente - Sair e entrar em todas as saídas, atravessar todos os pontes etc com GPS Boa sorte! :-) -- Johan Dahlin ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Aspectos a serem mapeados numa rodovia
Olha, eu fiz um trabalho de mapeamento há muitos anos atrás de avenidas de São Paulo, e eu acho que você tem que focar em algumas coisas, senão não mapeia nada. Eu tinha que mapear número de faixas, se era permitido estacionar, velocidade, semáforos, etc, etc... Na prática ficou bem difícil e acabei mapeando apenas o número de faixas e intereseções, que era o mais importante para o modelo de transporte que estávamos fazendo. Eu colocaria a seguinte ordem de prioridades: 1) rodovia duplicada/não duplicada; 2) número de faixas por sentido; 3) velocidade; 4) postos de serviços; 5) posto de polícia; 6) pedágios; 7) radares; 8) pontes; 9) etc, etc... Boa sorte 2010/5/21 Arlindo Pereira arli...@clavis.com.br Os trechos onde a rodovia tem postes de iluminação e onde não tem, para usar a tag lit=yes|no. Se é asfalto o tempo todo ou se tem partes de terra/pedras, para usar a tag surface=asphalt|cobblestone|dirt Divirta-se :) []s -- Arlindo Pereira Analista de Segurança Grupo Clavis Segurança da Informação http://www.clavis.com.br +55 21 2210-6061 +55 21 2561-0867 Em 21 de maio de 2010 13:45, Johan Dahlin jo...@gnome.org escreveu: 2010/5/21 Bráulio Bezerra da Silva brauliobeze...@gmail.com: Olá, pessoal Amanhã viajarei para João Pessoa de carro (de Natal, para quem não sabe onde moro). Eu queria algumas sugestões de coisas importantes a serem mapeadas. Já pensei em algumas, mas devo estar esquecendo de várias: - A rodovia --- Nº de faixas --- Retornos --- Entradas para outras estradas --- Pontes --- Obras - Postos de gasolina. - Cidade e povoados por onde a estrada passa (se bem que os dados do IBGE já cobrem quase tudo) - Pontos turísticos Bom, tem mais algumas coisas pra lembrar se você quer ter uma mapa boa: - Velocidade máxima - Pedágios - Borracharias - Radares - Nomes: aqui em SP muda frequentemente, SP-215 tem uns 5 nomes diferente - Sair e entrar em todas as saídas, atravessar todos os pontes etc com GPS Boa sorte! :-) -- Johan Dahlin ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Aspectos a serem mapeados numa rodovia
Eu tambem diria que é mais importante ser consistente do que completo (porque afinal é possível ser completo? :-) 2010/5/21 Vitor George vitor.geo...@gmail.com: Olha, eu fiz um trabalho de mapeamento há muitos anos atrás de avenidas de São Paulo, e eu acho que você tem que focar em algumas coisas, senão não mapeia nada. Eu tinha que mapear número de faixas, se era permitido estacionar, velocidade, semáforos, etc, etc... Na prática ficou bem difícil e acabei mapeando apenas o número de faixas e intereseções, que era o mais importante para o modelo de transporte que estávamos fazendo. Eu colocaria a seguinte ordem de prioridades: 1) rodovia duplicada/não duplicada; 2) número de faixas por sentido; 3) velocidade; 4) postos de serviços; 5) posto de polícia; 6) pedágios; 7) radares; 8) pontes; 9) etc, etc... Boa sorte 2010/5/21 Arlindo Pereira arli...@clavis.com.br Os trechos onde a rodovia tem postes de iluminação e onde não tem, para usar a tag lit=yes|no. Se é asfalto o tempo todo ou se tem partes de terra/pedras, para usar a tag surface=asphalt|cobblestone|dirt Divirta-se :) []s -- Arlindo Pereira Analista de Segurança Grupo Clavis Segurança da Informação http://www.clavis.com.br +55 21 2210-6061 +55 21 2561-0867 Em 21 de maio de 2010 13:45, Johan Dahlin jo...@gnome.org escreveu: 2010/5/21 Bráulio Bezerra da Silva brauliobeze...@gmail.com: Olá, pessoal Amanhã viajarei para João Pessoa de carro (de Natal, para quem não sabe onde moro). Eu queria algumas sugestões de coisas importantes a serem mapeadas. Já pensei em algumas, mas devo estar esquecendo de várias: - A rodovia --- Nº de faixas --- Retornos --- Entradas para outras estradas --- Pontes --- Obras - Postos de gasolina. - Cidade e povoados por onde a estrada passa (se bem que os dados do IBGE já cobrem quase tudo) - Pontos turísticos Bom, tem mais algumas coisas pra lembrar se você quer ter uma mapa boa: - Velocidade máxima - Pedágios - Borracharias - Radares - Nomes: aqui em SP muda frequentemente, SP-215 tem uns 5 nomes diferente - Sair e entrar em todas as saídas, atravessar todos os pontes etc com GPS Boa sorte! :-) -- Johan Dahlin ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Aspectos a serem mapeados numa rodovia
maximo peso maximo altura (e onde e marqueado fisica (placa amarelha) ou por lei (placa vermelho/branco) maxheight:physical maxheight:legal) maximo largura velocidade diferentiado (por exemplo maxspeed=110 - maxspeed:hgv=90) nome de ponte ou tunel farol/semaforo restricoes do virada (turn restrictions) mao unica/mao dupla zonas para ultrapassar emanquado (embankment=yes) quebra morro (traffic_calming=speed_bump) 2010/5/21 Claudomiro Nascimento Junior claudom...@claudomiro.com: Eu tambem diria que é mais importante ser consistente do que completo (porque afinal é possível ser completo? :-) 2010/5/21 Vitor George vitor.geo...@gmail.com: Olha, eu fiz um trabalho de mapeamento há muitos anos atrás de avenidas de São Paulo, e eu acho que você tem que focar em algumas coisas, senão não mapeia nada. Eu tinha que mapear número de faixas, se era permitido estacionar, velocidade, semáforos, etc, etc... Na prática ficou bem difícil e acabei mapeando apenas o número de faixas e intereseções, que era o mais importante para o modelo de transporte que estávamos fazendo. Eu colocaria a seguinte ordem de prioridades: 1) rodovia duplicada/não duplicada; 2) número de faixas por sentido; 3) velocidade; 4) postos de serviços; 5) posto de polícia; 6) pedágios; 7) radares; 8) pontes; 9) etc, etc... Boa sorte 2010/5/21 Arlindo Pereira arli...@clavis.com.br Os trechos onde a rodovia tem postes de iluminação e onde não tem, para usar a tag lit=yes|no. Se é asfalto o tempo todo ou se tem partes de terra/pedras, para usar a tag surface=asphalt|cobblestone|dirt Divirta-se :) []s -- Arlindo Pereira Analista de Segurança Grupo Clavis Segurança da Informação http://www.clavis.com.br +55 21 2210-6061 +55 21 2561-0867 Em 21 de maio de 2010 13:45, Johan Dahlin jo...@gnome.org escreveu: 2010/5/21 Bráulio Bezerra da Silva brauliobeze...@gmail.com: Olá, pessoal Amanhã viajarei para João Pessoa de carro (de Natal, para quem não sabe onde moro). Eu queria algumas sugestões de coisas importantes a serem mapeadas. Já pensei em algumas, mas devo estar esquecendo de várias: - A rodovia --- Nº de faixas --- Retornos --- Entradas para outras estradas --- Pontes --- Obras - Postos de gasolina. - Cidade e povoados por onde a estrada passa (se bem que os dados do IBGE já cobrem quase tudo) - Pontos turísticos Bom, tem mais algumas coisas pra lembrar se você quer ter uma mapa boa: - Velocidade máxima - Pedágios - Borracharias - Radares - Nomes: aqui em SP muda frequentemente, SP-215 tem uns 5 nomes diferente - Sair e entrar em todas as saídas, atravessar todos os pontes etc com GPS Boa sorte! :-) -- Johan Dahlin ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Neue Slippy Map (khtmlib)
Hallo Bernhard, die Beispielseiten gefallen mir. Das Spiel ist eine gute Idee. Könnte man für Schüler gebrauchen in Geographie. Da müßte man eine eigene Liste von Orten definieren können. Bei stufenlosen Zoom werden wohl die Kacheln mit der niedrigeren Auflösung vergrößert, bis die nächste Zoom-Stufe erreicht wird. Das sieht etwas pixelig aus. Hast Du mal probiert, ob es besser aussieht, wenn die Kacheln der höheren Auflösung verkleinert werden? Ich bekomme auf der Seite mit den OSM-Änderungen ab und zu eine Warnung Ein Skript auf dieser Seite ist eventuell beschäftigt oder es antwortet nicht mehr. Sie können das Skript jetzt stoppen oder fortsetzen, um zu sehen, ob das Skript fertig wird. Skript: http://www.khtml.org/osm/v0.52/khtml.js:1434 und manchmal wird das Firefox-Fenster für einige Zeit grau, d.h. es reagiert nicht mehr. Die Warnung über das nicht reagierende Skript kam auch mehrmals hintereinander, d.h. nach dem Schließen des Fensters mit Weiter ausführen kam ein paar mal sofort ein neues. Wenn Du mir sagst, was ich tun soll, helfe ich gern bei der Fehlersuche. (bin Softwareentwickler) Ich habe mit Firefox unter Linux (Ubuntu 64bit) getestet. Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Am Donnerstag 20 Mai 2010 23:43:30 schrieb Bernhard Zwischenbrugger: Hallo liebe Mapper Hallo Bernhard, Wer auf der englischen Liste mitliest, kennt meine map library wahrscheinlich schon. Jetzt funktioniert die Map auf den meisten Browsern und ich poste das jetzt auch auf diese Liste. Nein, lese ich nicht, danke für die Info :) Gefällt mir gut. Vorallem der feinere Zoom. Das Nachschieben (wenn ich während des Schiebens die Maustaste loslasse) ist ein nettes Gimmick und möchte es auch gar nicht schlecht reden - Design gehört ja schließlich auch dazu. Aber das Schieben ist dadurch teilweise schwerer, da es ungewollt weiter scrollt. Bei Coordinates stehen die aktuellen Parameter, durch Komma getrennt. Ist bei meinem firefox 3.0.19 nicht vom Punkt zu unterscheiden - aber auch kein Beinbruch. Getestete Browser: o Firefox firefox 3.0.19: keine weiteren Fehler entdeckt. o Konqueror Konqueror 3.5.10 (für mich aber vernachlässigbar :D ): Aufruf funktioniert, auch mit Permalink. Aber kein schieben oder zoomen möglich, weder Maus, noch Mausrad. Wenn ich auf fly back klicke tut sich zwar logischer Weise nichts, dafür pappt die Grafik aber am Mauszeiger, als würde ich sie wegziehen wollen. Wo soll ich weitermachen? Was fehlt? Die Ortsangabe in der Suche hat funktioniert. Allerdings wird nur der Ort, mit dem Land angezeigt. Da es den mehrfach gibt, steht das scheinbar Gleiche 5 mal untereinander. Vielleicht kannst du noch Bundesland, Kreis und ähnliches anzeigen lassen. Beim Vollbild (klasse Idee) werden die Koordinaten nicht übernommen. Hast Du mal über die Einbindung und Anzeige von GPX- und anderen Files nachgedacht? Tracks, WP's... Die Software die ich gemacht habe ist eine Map Library also sowas wie openlayers oder google maps api. Das einbinden der Karte sollte aber einmal so leicht sein wie mit google maps (oder einfacher). Es gefällt mir sehr gut vom Design her (z.B. der Zoombalken sieht nach was aus) und auch die Browserunterstützung. injooosm hat z.B. große Probleme mit dem IE :( Ich werde mir das später mal näher ansehen und evtl. als Option integrieren. liebe Grüße Bernhard MfG, Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Bernhard, Bernhard Zwischenbrugger wrote: Wer auf der englischen Liste mitliest, kennt meine map library wahrscheinlich schon. Jetzt funktioniert die Map auf den meisten Browsern und ich poste das jetzt auch auf diese Liste. Kannst Du mal einen kurzen Sales Pitch fuer uns machen - warum sollte man Deine Library benutzen anstatt OpenLayers, was sind aus Deiner Sicht die Vorteile/Unterschiede - und wo hat OpenLayers Dir vielleicht noch Features voraus? Welche grundsaetzlichen Maengel bei OpenLayers haben Dich dazu bewogen, etwas eigenes zu machen? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
On Fri, May 21, 2010 at 08:43:50AM +0200, Christian Knorr wrote: o Firefox firefox 3.0.19: o Konqueror Konqueror 3.5.10 (für mich aber vernachlässigbar :D ): Du solltest mal über ein Update deiner Sofware nachdenken. :) (Diese Versionen sehen nach Kubuntu 8.04 LTS aus. 10.04 LTS ist jetzt echt mal wieder ne brauchbare Version, probier's aus. :) Aufruf funktioniert, auch mit Permalink. Aber kein schieben oder zoomen möglich, weder Maus, noch Mausrad. Wenn ich auf fly back klicke tut sich zwar logischer Weise nichts, dafür pappt die Grafik aber am Mauszeiger, als würde ich sie wegziehen wollen. In einem aktuellen Konqueror konnte ich keine Fehler in der Bedienung feststellen. Die Ortsangabe in der Suche hat funktioniert. Allerdings wird nur der Ort, mit dem Land angezeigt. Da es den mehrfach gibt, steht das scheinbar Gleiche 5 mal untereinander. Vielleicht kannst du noch Bundesland, Kreis und ähnliches anzeigen lassen. Vielleicht einfach Nominatim einbinden? Dann ist auch Hausnummerngenaue Suche möglich. Wie schon gesagt wurde, wäre es vielleicht eine Option, z.B. ab der Hälfte bis zur nächsten Zoomstufe das nächste Tile verkleinert anzuzeigen. Bei Zoom 17.9 sieht es einfach nicht besonders gut aus. Gruß, Bernd pgpACiVSNEOzn.pgp Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Am Freitag 21 Mai 2010 09:03:21 schrieb Bernd Wurst: Konqueror 3.5.10 (für mich aber vernachlässigbar :D ): Du solltest mal über ein Update deiner Sofware nachdenken. :) (Diese Versionen sehen nach Kubuntu 8.04 LTS aus. 10.04 LTS ist jetzt echt mal wieder ne brauchbare Version, probier's aus. :) Du willst mir ernsthaft KDE4 empfehlen? :) Ein Update auf ubuntu 10.04 ist geplant (gnome), kein KDE mehr. Aber ich hab Angst um meinen 2 Schirm-Betrieb :( das wird wieder eine Gaudi... Aber 8.04 wird noch bis April 2013 supportet, zwar, wenn ich mich recht erinnere nicht für KDE, aber laufen tut es ja immer noch. Außerdem, wer surft schon mit dem Konqueror? Das Ding hat doch ohne ende Darstellungsfehler. Ist zumindest meine Erfahrung mit 8.04. In einem aktuellen Konqueror konnte ich keine Fehler in der Bedienung feststellen. Hast Du es nur getestet, oder nutzt Du den rege? Gruß, Bernd Chris.. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
NopMap schrieb: Ehrlich gesagt bin ich grade ziemlich ratlos - außer die Küstenlinie zu ignorieren und wieder auf händisch erzeugte Seepolygone zurückzugehen. Hat einer von Euch eine Idee, wie man das Problem in den Griff bekommen könnte? Hallo OSM2POWM macht es wie folgt (falls ich es noch richtig in Erinnerung habe) 1. Kuestenlinien sammeln und zusammenfuegen 2. Kuestenlinien auf die einzelnen Kacheln (hier 0.01° x 0.01°) splitten 3. Typ der einzelnen Kacheln aus der oceantiles_12.dat ermitteln (als moeglicher Typ, bzw. Vorschlag fuer einen Typ). Zu beziehen unter http://svn.openstreetmap.org/applications/rendering/png2tileinfo/oceantiles_12.dat 4. Kacheln fluten, ausgehend von den Kuesten-Kacheln und den darin enthaltenen Kuestenlinien. Dabei keine Kacheln die angeblich Land sind fluten. Hilft dann in den Alpen z.B. ;-) 5. Flaechen fuer das Wasser in den einzelnen Kacheln erzeugen 6. je nach Zoom-Stufe mehrere Kacheln (die Flaechen darin) zusamenfuegen und die Kontur und Inseln mit z.B. Douglas-Peucker vereinfachen. 7. freuen, wenn es halbwegs hinhaut... Leider funktioniert es nicht immer, da das GIGO-Prinzip immer noch guetig ist. ;-) http://de.wikipedia.org/wiki/Gigo Julian signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
On Fri, May 21, 2010 at 09:24:46AM +0200, Christian Knorr wrote: Konqueror 3.5.10 (für mich aber vernachlässigbar :D ): Du solltest mal über ein Update deiner Sofware nachdenken. :) (Diese Versionen sehen nach Kubuntu 8.04 LTS aus. 10.04 LTS ist jetzt echt mal wieder ne brauchbare Version, probier's aus. :) Du willst mir ernsthaft KDE4 empfehlen? :) Ich sage es ist mal wieder ne benutzbare Version. :) Nachdem es die Zwischenversionen geschafft haben, den Ruf von Kubuntu in Grund und Boden zu zerstören, ist das eben mal wieder etwas das in die richtige Richtung geht. Ein Update auf ubuntu 10.04 ist geplant (gnome), kein KDE mehr. Aber ich hab Angst um meinen 2 Schirm-Betrieb :( das wird wieder eine Gaudi... Aber 8.04 wird noch bis April 2013 supportet, zwar, wenn ich mich recht erinnere nicht für KDE, aber laufen tut es ja immer noch. Außerdem, wer surft schon mit dem Konqueror? Das Ding hat doch ohne ende Darstellungsfehler. Ist zumindest meine Erfahrung mit 8.04. Ich kenne den Gedankengang. Aber ein KDE-Nutzer wird Gnome nicht mögen. Ich habe es auch probiert. Da ist KDE4 wirklich immer noch besser. :) Ich glaube es wird OT. Probier's einfach mal aus. Am besten ist es, wenn man KDE4 vorher noch nie gesehen hat und die ganze Katastrophe um die bisherigen Releases einfach mal links liegen lässt. In einem aktuellen Konqueror konnte ich keine Fehler in der Bedienung feststellen. Hast Du es nur getestet, oder nutzt Du den rege? Ich hab grade mal Konqueror gestartet und die Karte dort laufen gelassen. Dabei konnte ich zoomen, verschieben und was man halt so mal eben mit einer slippymap macht. Nein, regulär nutzen will man Konqueror natürlich nicht, das ist mal klar. :) Gruß, Bernd pgpjcamOswnfY.pgp Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
Hallo Nop, ich bin derzeit am überlegen, ob ich mir nicht eine Küstenlinie extrahiere, diese dann soweit bearbeite, das alles passt und diese dann umtagge, negative ID's vergebe und mit dem jewiligen Planetfile merge. Über einen osmosis-Filter könnte man auch vorher natural=coastline herausfiltern, dann erspart man sich das umtaggen und Ersetzungsregeln im Composer, die wieder natural=coastline ausgeben. -- View this message in context: http://gis.638310.n2.nabble.com/Inkonsistente-Kustenlinien-tp5082833p5083176.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Arbeiten mit Osmosis (war: Re: W ohnmobil-Stellplätze bei OSM)
Hallo zusammen, Um die Datenmenge mit der ich arbeite klein zu halten, habe ich zunächst aus dem osm-File mittels 'osmosis' die 'nodes' und 'ways' die als 'tourism=caravan_site' getaggt sind, extrahiert. Ich arbeite hier mit dem Schweizer Ausschnitt (ca. 80 MB). Wenn ich mit Osmosis alle Toiletten (amenity=toilets) kopiere, dann dauert das 30 Minuten - ein Import der Schweiz mit osm2pgsql klappt aber in nur 6 Minuten und ich bin danach viel flexibler.. Ist Osmosis bei grösseren Datenmengen (im Verhältnis) schneller? Oder welche Vorteile hat Osmosis? Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM und Maxspeed
gibt es in JOSM einen Schalter, mit dem ich die Maxspeed Färbung ab- und anschalten kann? Es gibt in den Einstellungen Karteneinstellungen die Option Stile zu aktivieren und deaktivieren. http://n2.nabble.com/file/n5083227/Karsteneinstellungen.jpg Ich bin mir aber nicht ganz sicher, ob Du das meinst. Ansonsonten kannst Du noch alle Elemente, die das maxspeed Tag haben inaktiv schalten oder ausblenden mit dem Displayfilter. Dann kannst Du besser sehen, welche Elemente bereits ein maxspeed-Tag haben, ohne dass alles bunt wird. In den neueren Versionen von JOSM ist der Displayfilter in der linken Auswahlliste einfach auswählbar. Gruß Oliver http://n2.nabble.com/file/n5083227/Displayfilter-maxspeed.jpg -- View this message in context: http://gis.638310.n2.nabble.com/JOSM-und-Maxspeed-tp5082802p5083227.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Arbeiten mit Osmosis (war: Re: W ohnmobil-Stellplätze bei OSM)
Hallo, Thomas Ineichen wrote: Ich arbeite hier mit dem Schweizer Ausschnitt (ca. 80 MB). Wenn ich mit Osmosis alle Toiletten (amenity=toilets) kopiere, dann dauert das 30 Minuten - ein Import der Schweiz mit osm2pgsql klappt aber in nur 6 Minuten und ich bin danach viel flexibler.. Kommt drauf an, was Du machen willst. Osmosis erzeugt Dir halt einen echten OSM-Datensatz, den Du auch z.B. in den JOSM laden und bearbeiten und wieder hochladen kannst. *Diese* Flexibilitaet hast Du mit osm2pgsql nicht. Auch wird Osmosis Dir alle Tags extrahieren, osm2pgsql nur die, die Du per style-File anforderst (ausser natuerlich, Du bastelst mit dem neuen hstore-Zeug rum). Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
Hallo! aighes wrote: ich bin derzeit am überlegen, ob ich mir nicht eine Küstenlinie extrahiere, diese dann soweit bearbeite, das alles passt und diese dann umtagge, negative ID's vergebe und mit dem jewiligen Planetfile merge. Über sowas denke ich auch nach - das wär halt wieder ein anderer Weg zu manuell gepflegten, lokalen Seepolygonen. Falls wir nix besseres finden, laß uns zusammen dran arbeiten, das können wir dann gleich als Feature in Composer einbauen. Der knifflige Teil dabei dürfte es sein, die Küstenlinien dann wieder mit dem aktuellen Datenbestand zu mergen. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Inkonsistente-Kustenlinien-tp5082833p5083284.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Hi Bodo die Beispielseiten gefallen mir. Das Spiel ist eine gute Idee. Könnte man für Schüler gebrauchen in Geographie. Da müßte man eine eigene Liste von Orten definieren können. Ich habe die Liste der Hauptstädte aus der Wikipedia geparst: http://en.wikipedia.org/wiki/List_of_national_capital_cities_by_population So eine Liste händisch zu erstellen ist glaub sehr mühsam. Wenn es aber möglich wäre solche Listen direkt aus der OSM Datenbank zu erstellen, dann wäre das schon ein Hit. Ich werde mal osmxapi genauer anschauen - vielleicht geht es da. Ein richtiges Spiel ist es halt leider auch noch nicht. Nach 10 Hauptstädten ist es einfach nicht mehr interessant. Der Spielwitz fehlt. Vielleicht muss ich noch ein paar Monster zum abknallen einbauen ;-) Bei stufenlosen Zoom werden wohl die Kacheln mit der niedrigeren Auflösung vergrößert, bis die nächste Zoom-Stufe erreicht wird. Das sieht etwas pixelig aus. Hast Du mal probiert, ob es besser aussieht, wenn die Kacheln der höheren Auflösung verkleinert werden? Ich bin selbst Ubuntu Benutzer. Der Firefox verwendet beim Bilder Zoomen die nearest neighbor Methode. Der Firefox unter Windows verwendet da bereits eine andere Methode. Mit dem chromium wird das nicht pixelig aber dafür ein bisschen verschwommen. Es ist leicht möglich die Kacheln der höheren Auflösung zu verwenden. Einfach den Zoomfaktor im Browser ändern STRG-. Das Ergebnis ist aber nicht wirklich gut. Die Beschriftung wird zu klein und ist nicht mehr lesbar. Für Menschen mit schlechten Augen ist die Karte jetzt schon nicht verwendbar (sagt zumindest eine Freundin von mir die nicht mehr ganz gut sieht). Mit doppelclick kommt man übrigens immer auf einen richtigen (integer) Zoomlevel. Ich bekomme auf der Seite mit den OSM-Änderungen ab und zu eine Warnung Ein Skript auf dieser Seite ist eventuell beschäftigt oder es antwortet nicht mehr. Sie können das Skript jetzt stoppen oder fortsetzen, um zu sehen, ob das Skript fertig wird. Skript: http://www.khtml.org/osm/v0.52/khtml.js:1434 und manchmal wird das Firefox-Fenster für einige Zeit grau, d.h. es reagiert nicht mehr. Die Warnung über das nicht reagierende Skript kam auch mehrmals hintereinander, d.h. nach dem Schließen des Fensters mit Weiter ausführen kam ein paar mal sofort ein neues. Wenn Du mir sagst, was ich tun soll, helfe ich gern bei der Fehlersuche. (bin Softwareentwickler) Da kommt das ganze System an die Grenzen. Ein Problem das ich nicht lösen kann ist, dass die Datenbank einfach zu langsam ist. Im Moment geht das auf die OSM Hauptdatenbank und wenn das viele verwenden, dann werden das die Admins wahrscheinlich auch sperren weil die ganze DB in die Knie geht. Bei osmxapi gibt es die changesets nicht - das ist also auch keine Alternative. Hier ist ein Beispiel für eine langsame Abfrage: www.openstreetmap.org/api/0.6/changesets?bbox=104.838,11.536,105.010,11.577 Wenn viele Daten geladen werden, dann bekommen auch die Browser Probleme - das könnte ich aber vielleicht lösen. Eventuell löst sich das aber auch selbst wenn die Browser schneller werden (Firefox 3.7 bringt Hardwarebeschleunigung) liebe Grüße Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Am 21. Mai 2010 09:24 schrieb Christian Knorr os...@gmx.de: Du willst mir ernsthaft KDE4 empfehlen? :) Ein Update auf ubuntu 10.04 ist geplant (gnome), kein KDE mehr. Wir haben 2010... das pauschale KDE4 ist untauglich ist schon bei 4.3 reichlich dünn gewesen, bei 4.4 meines Erachtens einfach nur noch peinlich. Wenn du ein aktuelles KDE willst, nimm KDE4, wenn du GNOME lieber magst, nimm GNOME, aber was zwingt jemanden, der eigentlich lieber KDE nutzen würde, im Jahre 2010 noch zu GNOME? Gruß, Martin (seit 4.2 umgestiegen und zwischendurch auch durchaus genervt, jetzt ziemlich glücklich mit 4.4) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Am 20. Mai 2010 23:43 schrieb Bernhard Zwischenbrugger b...@datenkueche.com: Hallo liebe Mapper o iPhone/iPad mit multitouch zoom o Multitouch auf dem iPhone/iPad Da brauch ich jetzt aber Hilfe weil ich schon ein bisschen Betriebsblind bin ;-) Wo soll ich weitermachen? Was fehlt? o http://www.khtml.org/osm/v0.52/3d.html (perspekte für iPhone, iPad, Safari Mac) Wo soll ich weitermachen? liebe Grüße Bernhard Hi Bernard Tolle Sache. Prima gemacht! Auf dem IPod Touch ist diese Slippymap echt gut benutzbar (Im Gegensatz zu OpenLayers). Wünche ich mir für die Hauptseite. In der 3D Perspektive finde ich den Zoom etwas seltsam. Irgendwie verschiebt sich dabei der (gefühlte, also perspektivische) Mittelpunkt, oder irre ich mich? Netten Dank Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Häuser einzeichnen?
Am 20.05.2010 13:50, schrieb Friedhelm Schmidt: Da ich nicht kapiere wo man die BBOX Angaben machen muß, damit man einen WMS-Link für JOSM erzeugen kann, habe ich das Ergebnis runtergeladen. Das geht einfacher: Unter WMS | Berichtigtes Bild Geothings Mapwarper auswählen und darunter die ID deines Bilds eingeben. Die ID steht in der URL, z.b. für das Bild Miesbach, Germany: http://warper.geothings.net/maps/2596 ist die ID 2596 -fri- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hallo Friedhelm, vielen Dank für den Tipp. Funktioniert recht gut. Allerdings stört mich am Mapwarper, dass das korrigierte Bild eine sehr schlechte Auflösung hat. Gibt es dort irgendwo eine Stellschraube, damit man dieses Manko vermeiden kann? Denn wenn man in JOSM reinzoomt, dann sieht man von manchen Häusern nur noch Klötzchen. Die Datei die ich heute hochgeladen habe, war knapp 5MB groß, damit man auch noch Feinheiten sehen kann. Gruß Horst ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Häuser einzeichnen?
Am 21.05.2010 11:04, schrieb hike39: Allerdings stört mich am Mapwarper, dass das korrigierte Bild eine sehr schlechte Auflösung hat. Gibt es dort irgendwo eine Stellschraube, damit man dieses Manko vermeiden kann? Das stimmt leider. Ich habe die beste Erfahrung damit gemacht, die Bilder strikt selbst so zu re-samplen, dass die längste Kante knapp unter 1500 Pixeln liegt. Lade dir mal http://warper.geothings.net/maps/2601 in Josm (9.22259,49.14274,9.22692,49.14529) das sieht doch schon ganz ordentlich aus. Ach, noch ein Tipp: Wenn du in das Luftbild rein zoomst, kannst du mal rechts auf Ebenen, Geothings Marwarper rechtsklicken und Auflösung ändern auswählen. Dann wird das Bild in höherer Auflösung nachgeladen. -fri- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Check Traces vs gemappte Ways?
M∡rtin Koppenhoefer schrieb: Am 15. April 2010 17:51 schrieb olvagor o...@terbrueggen.net: Ich hab hier schon öfter den Fall gehabt, dass jemand im Wald GPS-Tracks hochgeladen aber dann keine Wege gezeichnet hat. Wenn ich das so mache dann entweder, weil der Empfang schlecht war, oder weil ich gar nicht auf Wegen unterwegs war. Blind fremde Tracks nachzuzeichnen und deren Ursache raten halte ich nicht für sinnvoll. Genau. Fremde Tracks zeichne ich grundsätzlich nicht einfach nach, ohne dass ich mal dort war. Mir haben aber schon öfters fremde Tracks geholfen, wenn ich gemerkt hab, dass mein Trace mal ein Stück lang miese Qualität hat. Wie gesagt - wenn ich selber dort war! Umgekehrt habe ich auch schon Traces hoch geladen, die ich nebenbei aufgenommen hab, ohne mich bewusst dort umzusehen. Solche Nebenbei-Traces ordne ich für mich genauso ein, wie fremde. Ich kann sie nicht einfach nachzeichnen, weil ich mir gar kein Bild machen kann, wie es dort eigentlich aussah. Für den aber, der die Gegend aktiv bearbeitet, können sie eine gute Hilfe sein. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Servus Christian Danke für die super Bugreports Gefällt mir gut. Vorallem der feinere Zoom. Das Nachschieben (wenn ich während des Schiebens die Maustaste loslasse) ist ein nettes Gimmick und möchte es auch gar nicht schlecht reden - Design gehört ja schließlich auch dazu. Aber das Schieben ist dadurch teilweise schwerer, da es ungewollt weiter scrollt. Das hatte mit Design wenig zu tun, das war einfach Fehlerhaft ;-) Ich hab das jetzt geändert und das Nachschieben erfolgt nur noch aber einer gewissen Geschwindigkeit. Bei Coordinates stehen die aktuellen Parameter, durch Komma getrennt. Ist bei meinem firefox 3.0.19 nicht vom Punkt zu unterscheiden - aber auch kein Beinbruch. Jetzt ist ein | drinnen. Schaut besser aus. Die Ortsangabe in der Suche hat funktioniert. Allerdings wird nur der Ort, mit dem Land angezeigt. Da es den mehrfach gibt, steht das scheinbar Gleiche 5 mal untereinander. Vielleicht kannst du noch Bundesland, Kreis und ähnliches anzeigen lassen. Sodala, jetzt ist nominative drinnen. Mit dem alten namefinder war ich nicht zufrieden weil er einfach zu langsam war. Deshalb habe ich geonames verwendet. Nominative scheint jetzt aber gut zu funktionieren. Beim Vollbild (klasse Idee) werden die Koordinaten nicht übernommen. Sollte jetzt funktionieren. Hast Du mal über die Einbindung und Anzeige von GPX- und anderen Files nachgedacht? Tracks, WP's... Ja klar. GPX, KML, OSM-XML werd ich alles einbauen. Eigentlich hab ich es schon gemacht - allerdings halt nur als Quickhack. KML ist natürlich ein gewaltiger Standard - da werde ich wohl nicht alles machen. Die Software die ich gemacht habe ist eine Map Library also sowas wie openlayers oder google maps api. Das einbinden der Karte sollte aber einmal so leicht sein wie mit google maps (oder einfacher). Es gefällt mir sehr gut vom Design her (z.B. der Zoombalken sieht nach was aus) und auch die Browserunterstützung. injooosm hat z.B. große Probleme mit dem IE :( Ich werde mir das später mal näher ansehen und evtl. als Option integrieren. Der IE ist natürlich ein eigenes Thema. Viel getestet hab ich nicht mit dem IE - sollte aber funktionieren. Der Android Browser ist auch so ein Schmudelkind - das mögen aber die Android Handy Besitzer aber gar nicht hören ;-) lg Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
Viel zu arbeiten ist da egtl. nicht. Ich hab mir die planet-Datei zurechtgeschnitten und daraus dann die Küstenlinien rausgefiltert. osmosis aufruf, so wie es der Composer macht, nur anstatt von --bounding-box... --tf accept-ways natural=coastline --tf reject-relations --used-node Dann hab ich die Datei in josm geladen und die entsprechenden Stellen gelöscht und wieder abgespeichert. Hilfreich finde ich dazu das Plugin slippymap. Damit sieht man dann, was der coastline-Kreis sein soll. Nun die Datei im Editor öffnen und id=' mit id='-, ref=' mit ref='- und coastline mit bspw. own_coastline ersetzen. Jeweils immer mit alles ersetzen und wiederum speichern ( und jeweils weglassen ;-)). Im Anschluss merge ich die beiden Dateien zusammen. --read-xml-0.6 file=... --sort-0.6 --read-xml-0.6 file=... --sort-0.6 --merge --write-xml file=... Mal schauen, was der Composer zu der fertigen Datei sagt... (bin gerade am mergen) Viele Grüße, aighes -- View this message in context: http://gis.638310.n2.nabble.com/Inkonsistente-Kustenlinien-tp5082833p5083608.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mapping von maxspeed:forward und maxspeed:backward
Moin, mich würde interessieren, ob jemand von euch zu folgendem Problem noch ein paar nützliche Tipps hat: Idealer weise mappt man maxspeed indem man den selben Weg hin und wieder zurück fährt. Nur so fällt einem auf, ob die Geschwindigkeitsbegrenzungen in beiden Fahrtrichtungen synchron sind. Fährt man den Weg nur in eine Richtung ab, so kann man dies nicht feststellen und bemerkt daher in aller Regel auch nicht ob man es anstatt eines maxspeed tatsächlich mit einem maxspeed:forward bzw. maxspeed:backward zu tun hat. Fährt man die Strecke nur in eine Richtung, so erscheint alles als maxspeed= Wie lässt es sich nun am günstigsten vermeiden, dass jemand der die Strecke in Gegenrichtung abfährt und ein in seiner Richtung nicht vorhandenes maxspeed vorfindet dieses nicht löscht sondern in ein maxspeed:forward bzw. maxspeed:backward umwandelt. Mit anderen Worten wie mache ich am günstigsten darauf aufmerksam, dass sich meine Eintragungen in der Datenbank nur Beobachtungen für eine Fahrtrichtung enthalten. Alles erst einmal nur als maxspeed:forward bzw. maxspeed:backward taggen, in der Hoffnung, dass der Nächste, der die Strecke aus der Gegenrichtung abfährt ggf. die synchronen Abschnitte in ein maxspeed umwandelt? Da es deutlich mehr synchrone als asynchrone Geschwindigkeitsbegrenzungen gibt erscheint mir dieses Vorgehen nicht wirklich sinnvoll. Zumal der Gegenrichtungsfahrer eine solche Datenbankeintragung auch erst einmal richtig interpretieren muss. Danke Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
Hallo, NopMap wrote: Eigentlich ist die Aufgabenstellung ganz einfach: Ich versuche, eine Garminkarte von Mitteleuropa zu erzeugen, mit Meerespolygonen, die per mkgmap aus den natural=coastline Tags erzeugt werden. Kannst Du nicht die processed_p-Kuestenlinien nehmen und daraus schnell Pseudo-OSM-Daten fuer den mkgap bauen? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM städtisch ausgelegt. Land brauch t den cyclefootway
Martin Simon schrieb: Am 19. Mai 2010 08:35 schrieb Karl Eichwalder k...@gnu.franken.de: +1, so isses. -1, das ist falsch und das weißt auch du. Noch einmal: wenn du es nicht magst, benutze es nicht, sondern das alternative foot/cycle/bridleway-Schema - aber hör auf, hier das tag zu verbiegen. Ja, genau! Genaugenommen kann Path mit den entsprechenden Attributen alles abbilden, was schmaler als ein Weg ist. Neue Tags, die das Spektrum von highway=* noch breiter machen halte ich nicht für so sinnvoll. Für besser halte ich, Attribute zu benutzen, die z.B. highway=track genauer beschreiben. Auch dürfte das der Entwicklung der verschiedene Renderer entgegenkommen. highway=path können sie ohnehin darstellen, auch wenn sie die Attribute noch nicht komplett auswerten. Wenn man der Meinung ist, dass Pfade mit bestimmten Attributen abweichend dargestellt werden sollen, kann man das später auch in den Renderer einbauen. Man kann mit einer überschaubaren Menge an Attributen eine große Zahl verschiederer Tags mit bestimmten Eigenschaften versehen, die von der Software oft generisch behandelt werden können. Also von mir ein klares NEIN zu cyclefootway oder ähnlichen Konstruktionen. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Am 21.05.2010 10:35, schrieb Bernhard Zwischenbrugger: Ich habe die Liste der Hauptstädte aus der Wikipedia geparst: http://en.wikipedia.org/wiki/List_of_national_capital_cities_by_population So eine Liste händisch zu erstellen ist glaub sehr mühsam. Wenn es aber möglich wäre solche Listen direkt aus der OSM Datenbank zu erstellen, dann wäre das schon ein Hit. Hallo Bernhard, meine Idee für Schüler wäre die Erstellung von Listen passend zum gewünschten Thema, beispielsweise europäische Hauptstädte, Hauptstädte der deutschen Bundesländer, Kreisstädte, Berge, Flüsse usw. Die Liste der zu findenden Orte könnte man manuell erstellen oder wenn eine passende Quelle (Wikipedia) vorhanden ist, auch automatisch extrahieren. Es sollte eine Möglichkeit zum automatischen Ermitteln der Zielkoordinaten geben. Vielleicht kann man eine Datei mit den erforderlichen Daten irgendwo hochladen und in der Spiel-URL einen Verweis auf die Datei angeben. So könnte man eine eigene Spielversion mit individueller Auswahl benutzen. Weitere Idee: Ziele zufällig sortieren Es ist leicht möglich die Kacheln der höheren Auflösung zu verwenden. Einfach den Zoomfaktor im Browser ändern STRG-. Das Ergebnis ist aber nicht wirklich gut. Die Beschriftung wird zu klein und ist nicht mehr lesbar. Der Zoonfaktor im Browser hat bei mir nur die Wirkung, daß generell alles skaliert wird und dadurch unscharf aussieht. Das ändert aber nichts am grundsätzlichen Verhalten. Ich meine die Umschaltung der Kacheln beim stufenlosen Zoom der Karte: Wenn ich beispielsweise den Zoom von 14 aus langsam hochstelle, werden die Grafiken immer weiter vergrößert und damit bei mir pixelig. Geht dann der Zoom von 14,9 auf 15, werden die Kacheln im nächsten Zoom-Level verwendet und sehen wieder gut aus. Auch mit geändertem Browser-Zoom wird es von 15 zu 14,9 pixelig. Wie sieht es aus, wenn bei 14,1 bis 14,9 nicht die Bilder von Zoomlevel 14 vergrößert werden, sondern die Bilder von 15 verkleinert? Oder den Sprung in die Mitte legen, beispielsweise im Bereich von 14,6 bis 15,5 die Kacheln in Zoom 15 verwenden? Viele Grüße Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AKÜFI (was: AIO keine Adressen mehr )
Christian Knorr glaubte zu wissen: Nun zur Sache: mir fehlt absolut die Phantasie, was mit NKIN wambacher Ich hab das als Fipptehler gewertet und als NEIN gelesen. Auch wenn ich den Sinn nicht so recht entschlüsseln konnte/wollte. oder -v ausgedrückt werden soll. Einigen Programmen kann man auf der Kommandezeile die Option -v mtgeben, was für das Programm heißt Sei mal ausführlicher. flo -- Trotz mehrfacher muendlicher Anmahnung ist das Kuechenfenster bis heute noch nicht ordnungsgemaess dekoriert. [Der Rechtsanwalt eines Vermieters] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Hallo, als Nutzer der Karten wäre es mir wichtig, dass diese einfach eingebunden werden können. Ich übergebe ihm im funktionsaufruf die BoundingBox und bspw. eine gpx-Datei und den Rest macht dann dein Skript. Das Zoomverhalten an sich finde ich super, allerdings durch die Unschärfe ist die Karte kaum zu gebrauchen. Viele Grüße, aighes -- View this message in context: http://gis.638310.n2.nabble.com/Neue-Slippy-Map-khtmlib-tp5081762p5083733.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Servus Frederik Kannst Du mal einen kurzen Sales Pitch fuer uns machen - warum sollte man Deine Library benutzen anstatt OpenLayers, was sind aus Deiner Sicht die Vorteile/Unterschiede - und wo hat OpenLayers Dir vielleicht noch Features voraus? Welche grundsaetzlichen Maengel bei OpenLayers haben Dich dazu bewogen, etwas eigenes zu machen? Die großen Unterschiede: o Zoom Speed o nicht integer Zoomlevel o Multitouch am iPhone/iPod Angefangen hab ich mit einer Karte für das iPhone. Multitouch macht nur Sinn wenn man fliessende Zoomlevel zulässt. Für die webkit Desktop Browser war das dann leicht zu adaptieren. Am Firefox auf Linux schaut das natürlich beschissen aus, weil die Bilder mit der nearest neighbour Methode gezoomt werden. Mit chromium funktioniert das aber schon ganz fein. Wenn man ein klares Bild will, dann kann man doppelklick auf den nächsten Zoomlevel scharfstellen. Wirklich interessant ist die map mit Chromium 5 (beta) und einem schnellen TileServer. Es kommt eine dritte Dimension dazu. Ich hoffe Google verklagt mich jetzt nicht gleich aber hier hab ich mal den Google Tileserver in Verwendung: http://www.khtml.org/osm/v0.57/google.html (das ist illegal und ich werde es wieder entfernen) OpenLayers kenn nur Integer Zoom Level. Das rein optische Navigieren finde ich bei OL eher schwierig. Bei einem doppelklick wird bei OL die Karte neu aufgebaut und ich verirre mich immer. Rauszoomen und an einer anderen Stelle wieder reinzoomen macht bei OL nicht wirklich spass. OpenLayers kann natürlich viel mehr. Ich kenne OL nicht wirklich, aber mir fallen jetzt folgende Dinge ein: o Layers o GPX o KML o andere Koordinaten Systeme (nicht WGS84) o ... Eventuell wäre es möglich meine Map in OL zu integrieren - dürfte aber doch eher schwierig sein. Andererseits denke ich, dass es recht einfach sein sollte, diese Dinge in meine Karte einzubauen. Schwierig ist aber aber wiederum die Geschwindigkeit nicht zu verlieren. Im Moment probiere ich die API richtig zu machen. Ich möchte die Dinge die für Geschwindigkeit zuständig sind klar vom Rest Trennen. Wenn Dinge nur auf Geschwindigkeit optimiert sind, dann wird der Programm Code einfach nicht schön und nicht leicht wartbar. Eine low level API ist daher wichtig. lg Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Das Zoomverhalten an sich finde ich super, allerdings durch die Unschärfe ist die Karte kaum zu gebrauchen. Ja leider. Man muss schon die ganzen Zoomstufen exakt treffen, damit man sich nicht die Augen reiben muss ob der Unschärfe. - Wenn die Animation so toll gefällt, dann kann man sie ja trotzdem drinlassen, aber eben nur auf ganzen Zoomstufen einrasten lassen. - Koordinateneingabe (im Suchfeld) funktioniert nicht, zumindest nicht mit den Notationen die google-maps versteht. (für osm.org gibt's da ein greasemonkey-script, was das nachrüstet.) - Wenn man über die Suche den dargestellten Bereich wechselt, dann bleiben die zuvor gesetzten Entfernungs-Marker drin, selbst wenn die Entfernung auf Grund der Projektion (andere Äquatordistanz) hier überhaupt nicht mehr passen kann. - Wenn ich im Firefox (3.6) den Zoom-Wert umschalte, verrutscht der Kartenausschnitt spontan irgendwo ins Wasser bei Grönland -jha- P.S. Was dieser Linux-Flameware unter diesem Topic auf dieser Liste soll bleibt mir ein Rätsel. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Hallo Bernhard, die Idee von Bodo finde ich gut: Sprung in die Mitte legen, beispielsweise im Bereich von 14,6 bis 15,5 die Kacheln in Zoom 15 verwenden? Vielleicht legt man den Sprung bei #,3? 14,0..14,3 von z=14 vergrössern 14,4..14,9 von z=15 verkleinern (oder so) Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
Hallo, leider mochte er Comopser meine preparierte Datei nicht. Hast du eine Ahnung, wass da falsch gelaufen sein könnte? Unter http://www.aighes.de/data/coastline_germany.7z hab ich mal die Datei mit den geänderten Küstenlinien hochgeladen. java.lang.IllegalArgumentException: nodes ids are not in ascending order Exception analyzing data for Germany java.lang.IllegalArgumentException: nodes ids are not in ascending order at nop.osm.nodeindex.NodeIndex.storeNode(NodeIndex.java:80) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:302) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:309) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:309) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:309) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:309) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:309) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:309) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:309) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copyTo(NodeTree.java:285) at nop.osmc.generator.An alyzer.standardAn alysis(An alyzer.java:120) at nop.osmc.generator.An alyzer.an alyze(An alyzer.java:69) at nop.osmc.generator.Mapper.generate(Mapper.java:183) at nop.osmc.MapComposer$12.act(MapComposer.java:378) at nop.gui.MenuThreadAction.run(MenuThreadAction.java:27) at java.lang.Thread.run(Unknown Source) -- View this message in context: http://gis.638310.n2.nabble.com/Inkonsistente-Kustenlinien-tp5082833p5083919.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Am 20.05.2010 um 23:43 schrieb Bernhard Zwischenbrugger: Features: o Schnelles stufenloses zoomen mit dem Mausrad o Multitouch auf dem iPhone/iPad o Vektor Graphik Wie wäre es mit Multitouch für die normalen Browser? Bei MacBooks hat man mit dem wunderbaren Glastrackpad die gleichen Zoomgesten wie auf dem iPhone/iPad. Bei deiner Webseite zoomt man damit aber leider nicht die Karte sondern die ganze Webseite. Falls man das umstellen kann auf nur die Karte wäre das super und viel besser nutzbar. -Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Falsche(?) hamlets
Am 19. Mai 2010 16:11 schrieb René Falk li...@falconaerie.de: Die Gemeinde Bodolz daneben hat ebenfalls mehrere Ortsteile [2], doch sind manche nicht größer als ein Weiler. Wäre hier hamlet für alle Ortsteile die richtige Lösung? Hängt davon ab, wie es vor Ort ausschaut. Ist ein Ortsteil eher ein Dorf als ein Weiler, würde ich ihn auch als village taggen. Wenn der Ortsteil eher wie ein Weiler ausschaut, dann hamlet. +1, die manchen, die Weiler sind, als hamlet, und die die Dörfer sind als village. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
hi Sprung in die Mitte legen, beispielsweise im Bereich von 14,6 bis 15,5 die Kacheln in Zoom 15 verwenden? Vielleicht legt man den Sprung bei #,3? 14,0..14,3 von z=14 vergrössern 14,4..14,9 von z=15 verkleinern (oder so) Jetzt hab ich mal den Sprung bei 0.5 gemacht: http://www.khtml.org/osm/v0.57.5/ Das Problem ist jetzt, dass die Schrift verdammt klein wird. Zudem muss der Browser viel mehr Kacheln laden und alles wird langsamer. Für den Firefox mit Linux hilft das aber alles nichts, das ist ein anderes Problem. Mit Doppelklick kommt man aber immer auf einen scharfen Zoomlevel. Es wäre natürlich möglich immer automatisch auf einen ganzzahligen Zoomwert zu kommen. Also so wie bei google oder bing maps. Ich werde einen Parameter einbauen der das ermöglicht. lg Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] TMC Points
Hi Ich habe ich in den letzten Tagen an Taggen von TMC gemacht. Mittlerweile frage ich mich allerdings ob TMC Location Points nicht fast immer eher ein Weg ist oder sogar eine Relation mit mehreren Wegen als Mitglieder. Wie ich aus der Diskussion vor ein paar Monaten gelesen habe gibt es da ja keine einheitlichen Schemata. cu colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
On Fri, May 21, 2010 at 02:43:22PM +0200, Bernhard Zwischenbrugger wrote: Jetzt hab ich mal den Sprung bei 0.5 gemacht: http://www.khtml.org/osm/v0.57.5/ Das Problem ist jetzt, dass die Schrift verdammt klein wird. Optisch ist das IMHO viel besser. Zudem muss der Browser viel mehr Kacheln laden und alles wird langsamer. Das mit den mehr Kacheln ist natürlich ein schwer zu lösendes aber valides Problem. Für den Firefox mit Linux hilft das aber alles nichts, das ist ein anderes Problem. Ich versteh das gar nicht. Wird das definitiv in 3.7 gefixed oder muss man irgendwo für einen Bugreport voten? ;-) Ist ja nicht so, dass Linux irgendwie per se keine normalen Skalierungen unterstützen würde... Mit Doppelklick kommt man aber immer auf einen scharfen Zoomlevel. Gut zu wissen. :) Es wäre natürlich möglich immer automatisch auf einen ganzzahligen Zoomwert zu kommen. Also so wie bei google oder bing maps. Ich werde einen Parameter einbauen der das ermöglicht. Das wäre vermutlich für einen Großteil der Benutzer der bevorzugte Weg, denn skalierte Pixelgrafiken sind halt immer nich ganz das gelbe vom Ei. Wäre die Frage, ob du dich hier als eierlegende Wollmichsau aufstellen willst und alle Anwendungsgebiete optimal abbilden möchtest oder ob du sagst, dir ist eine Alternative zu OpenLayers wichtig, die eben eine andere Zielgruppe hat. Ich denke mal smooth-zooming sollte sich auch in OpenLayers irgendwie einbauen lassen. Wenn jetzt also die Linux-Firefox-User nicht wirklich in deine Zielgruppe passen, weil die eher OpenLayers-Seiten anschauen solltest, dann musst du natürlich auch nicht einbauen was nur die wollen. :) Gruß, Bernd pgpX4DV40A9Y1.pgp Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Hallo, Bernd Wurst wrote: Wäre die Frage, ob du dich hier als eierlegende Wollmichsau aufstellen willst und alle Anwendungsgebiete optimal abbilden möchtest oder ob du sagst, dir ist eine Alternative zu OpenLayers wichtig, die eben eine andere Zielgruppe hat. Wenn ich das richtig verstanden habe, ging es darum, dass das sanfte Zoomen halt besser in die iWhatever-Welt mit der Fingerbedienung passt. Vielleicht waere es ein guter Kompromiss, wenn das Standardverhalten der Library vom User Agent abhinge? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Bernhard Zwischenbrugger b...@datenkueche.com wrote: Am Firefox auf Linux schaut das natürlich beschissen aus, weil die Bilder mit der nearest neighbour Methode gezoomt werden. Rasterbilder dieser Art mit wenig Details und wenig verscheidenen Farben. Typische Kartenkacheln halt will man eigentlich nicht skalieren da finde ich ehrlich gesagt die Idee das überhaupt zu tun broken. Was man eigentlich haben will, was aber derzeit nur mit high end OpenGL Hadrware halbwegs performant geht ist on the fly rendern :) Ich hoffe Google verklagt mich jetzt nicht gleich aber hier hab ich mal den Google Tileserver in Verwendung: http://www.khtml.org/osm/v0.57/google.html (das ist illegal und ich werde es wieder entfernen) Das ist nicht vergleichbar, weil Du hier Sattelitenbilder und Luftbilder hast. Da gibt es _erhblich_ weniger Skalierungsartefakte. Wenn Du die Kartentiles von Google nimmst statt der Bilder sieht das sicher genauso besch** aus, weil eben Rasterbilder skaliert werden müssen. OpenLayers kenn nur Integer Zoom Level. Its not a bug, ... siehe oben :) Sven -- Those who do not understand Unix are condemned to reinvent it, poorly (Henry Spencer) /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] Neue Slippy Map (khtmlib)
hi Ich versteh das gar nicht. Wird das definitiv in 3.7 gefixed oder muss man irgendwo für einen Bugreport voten? ;-) Das Voten ist heutzutage ganz einfach: chromium verwenden Ist ja nicht so, dass Linux irgendwie per se keine normalen Skalierungen unterstützen würde... Ich hab jetzt mit dem FF 3.7 alpha getestet. Da ändert sich leider nichts. In der Windows Version wird Direct 2D eingebaut was das zoomen von Bildern sehr verbessert. Die Linux Version ist da aber ein bisschen hinten. Es wäre natürlich möglich immer automatisch auf einen ganzzahligen Zoomwert zu kommen. Also so wie bei google oder bing maps. Ich werde einen Parameter einbauen der das ermöglicht. Das wäre vermutlich für einen Großteil der Benutzer der bevorzugte Weg, denn skalierte Pixelgrafiken sind halt immer nich ganz das gelbe vom Ei. Wäre die Frage, ob du dich hier als eierlegende Wollmichsau aufstellen willst und alle Anwendungsgebiete optimal abbilden möchtest oder ob du sagst, dir ist eine Alternative zu OpenLayers wichtig, die eben eine andere Zielgruppe hat. Ich denke mal smooth-zooming sollte sich auch in OpenLayers irgendwie einbauen lassen. Die Variante die immer auf einen ganzzahligen Zoomwert snappt ist mit openLayers sicher leicht machbar. Man müsste nur wärend der Zoomanimation die Vektor Daten ausblenden um eine flüssige Animation zu bekommen. Wenn jetzt also die Linux-Firefox-User nicht wirklich in deine Zielgruppe passen, weil die eher OpenLayers-Seiten anschauen solltest, dann musst du natürlich auch nicht einbauen was nur die wollen. :) Ich bin ja selbst Firefox Linux User. Es geht mir nicht darum OpenLayers zu verdrängen. Viel interessanter wäre es die User von Bing und Google zu gewinnen. lg Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.05.2010 14:43, schrieb Bernhard Zwischenbrugger: Jetzt hab ich mal den Sprung bei 0.5 gemacht: http://www.khtml.org/osm/v0.57.5/ Das Problem ist jetzt, dass die Schrift verdammt klein wird. Zudem muss der Browser viel mehr Kacheln laden und alles wird langsamer. Ich persönlich finde es so schöner. Für den Firefox mit Linux hilft das aber alles nichts, das ist ein anderes Problem. Ich meine, es hilft doch. Die verkleinerten Kacheln sehen jedenfalls besser aus als die vergrößerten. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv2lJoACgkQnMz9fgzDSqeU2ACfbpcC4uj4z7GhL0BbREw92rvu BKYAoID6B5oQ0IDbQM5vyVvDRLcNPTA5 =SobZ -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
On 21.05.2010 13:35, Bernhard Zwischenbrugger wrote: Servus Frederik Kannst Du mal einen kurzen Sales Pitch fuer uns machen - warum sollte man Deine Library benutzen anstatt OpenLayers, was sind aus Deiner Sicht die Vorteile/Unterschiede - und wo hat OpenLayers Dir vielleicht noch Features voraus? Welche grundsaetzlichen Maengel bei OpenLayers haben Dich dazu bewogen, etwas eigenes zu machen? Die großen Unterschiede: o Zoom Speed o nicht integer Zoomlevel o Multitouch am iPhone/iPod Das sieht gut aus und fühlt sich auch gut an. Das mit dem integer-Zoom bei OL stimmt aber nicht, siehe: http://openlayers.org/dev/examples/fractional-zoom.html Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
On Fri, May 21, 2010 at 03:55:20PM +0200, Bernhard Zwischenbrugger wrote: Ich versteh das gar nicht. Wird das definitiv in 3.7 gefixed oder muss man irgendwo für einen Bugreport voten? ;-) Das Voten ist heutzutage ganz einfach: chromium verwenden Hm. Nein. :) Ist ja nicht so, dass Linux irgendwie per se keine normalen Skalierungen unterstützen würde... Ich hab jetzt mit dem FF 3.7 alpha getestet. Da ändert sich leider nichts. In der Windows Version wird Direct 2D eingebaut was das zoomen von Bildern sehr verbessert. Die Linux Version ist da aber ein bisschen hinten. Okay, Direct2D ist natürlich wenig Plattformübergreifend aber hat wohl keine direkte Konkurrenz als High-Level-2D-API. Andererseits sollte der verwendete Algorithmus ja auch locker in Software möglich sein, wir reden hier ja noch nichtmal von Gechwindigkeit. Mit freundlichen Grüßen, Bernd Wurst -- Bernd Wurst, Administration E-Mail/Jabber: be...@schokokeks.org schokokeks.org GbR, Bernd Wurst, Johannes Böck Köchersberg 25, 71540 Murrhardt http://schokokeks.org pgp4IOKpvRaX4.pgp Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Rasterbilder dieser Art mit wenig Details und wenig verscheidenen Farben. Typische Kartenkacheln halt will man eigentlich nicht skalieren da finde ich ehrlich gesagt die Idee das überhaupt zu tun broken. Als Überblend-Effekt finde ich das schon nett. Wenn die Leistung des Clients das hergibt, ist das einfach schöner als nur schöne die eingeblendete Kacheln auszutauschen. Aber das war's dann auch schon. Benutzen möchte man den Pixelmatsch nicht... -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Hallo, Johann H. Addicks wrote: Aber das war's dann auch schon. Benutzen möchte man den Pixelmatsch nicht... Naja, ich kann mich (trotz Apple-Abstinenz) da schon reinversetzen. Wenn ich auf einer Europakarte den Zeigefinger auf Karlsruhe und den Daumen auf Muenchen lege und das beides nun scherenmaessig auseinanderschiebe, will ich ja, dass nach Ende der Bewegung immer noch der Zeigefinger auf Karlsruhe und der Daumen auf Muenchen ist - und solange man kein Force Feedback hat, um vom Geraet aus die Finger an die richtige Stelle zu schieben, muss man halt Zoomzwischenstufen benutzen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohnmobil-Stellplätze bei OSM
Jan Tappenbeck schrieb: Am 19.05.2010 09:50, schrieb Martin Mainzer: Hallo, ich habe mich in den letzten Wochen mit den Wohnmobil-Stellplätzen in OSM (tourism=caravan_site) beschäftigt. Um diese Daten für Leute die mit Wohnmobilien unterwegs sind, nutzbar zu machen habe ich POI-Dateien für Navis und eine OpenLayer Karte für Europa mit den Stellplätzen erstellt (beides auf meiner User-Site: http://wiki.openstreetmap.org/wiki/User:Marmai). Bei der Arbeit mit den Daten ist mir aufgefallen, dass zwar schon eine Menge an Wohnmobilstellplätzen in Deutschland verzeichnet ist (560, Europa 1447), aber kaum weitergehende Informationen eingetragen sind. Ich denke, dass es insbesondere interessant wäre zu wissen, ob die Stellplätze kostenlos oder kostenpflichtig sind (fee=*) und ob Stromanschlüsse vorhanden sind (power_supply=*). Vielleicht können diese Informationen noch an der einen oder anderen Stelle ergänzt werden, und dadurch der Wert von OSM-Daten für Wohnmobil-Reisende deutlich erhöht werden. Viele Grüße, Martin Hi ! am besten Du erstellt ein Ticket [1] dafür und legst gleich ein Present [2] bei. Gruß Jan :-) [1] http://josm.openstreetmap.de/newticket [2] http://wiki.openstreetmap.org/wiki/DE:Anpassen_der_Vorlagen_von_JOSM Hallo Jan, ich habe nun ein Ticket erstellt, und ein 'preset' angelegt [1]. Da ich beides zum ersten Mal gemacht habe, wäre es super, wenn Du mal schauen könntest ob das so für die josm-Entwickler verständlich ist und ob im preset keine gravierenden Fehler stecken. Gruß, Martin [1] http://josm.openstreetmap.de/ticket/5056 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
Am 21. Mai 2010 07:46 schrieb NopMap ekkeh...@gmx.de: Kurz gesagt: Die Küstenlinien werden ebenso schell wieder beschädigt wie sie repariert werden können und es ist mir in den letzten 3 Wochen nicht gelungen, zufällig ein Planetfile mit komplett intakten Küstenlinien zu erwischen. Ehrlich gesagt bin ich grade ziemlich ratlos - außer die Küstenlinie zu ignorieren und wieder auf händisch erzeugte Seepolygone zurückzugehen. Hat einer von Euch eine Idee, wie man das Problem in den Griff bekommen könnte? technisch fällt mir keine Lösung ein, aber man könnte auch versuchen, dem auf der comunity-Ebene beizukommen: - in den mapfeatures explizit einen Hinweis (ggf. noch prominenter) anbringen, wo coastlines _nicht_ eingesetzt werden sollen, und erklären, warum das sensibel ist - coastline aus den presets entfernen und in autocomplete nicht anbieten (dabei von der Prämisse ausgehen, dass a) die coastlines bereits irgendwie halbwegs drin sind, und daher das Tag äusserst selten an _neue_ Wege gesetzt werden muss b) das Editieren von coastlines irgendwie Profiaufgabe ist, wo man dann auch den Tag kennen wird c) das betrifft ja auch nicht diejenigen Edits, wo man bestehende Coastlines verfeinert und in der Position korrigiert) - hier (und ggf. im Forum und in den anderen Listen) eine Diskussion anstoßen/das Augenmerk darauf richten Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massendownloads vom PCN - portale geografico nazionale
Am 20. Mai 2010 14:37 schrieb Bodo Meissner o...@bodo-m.de: Am 18.05.2010 16:50, schrieb M∡rtin Koppenhoefer: OSM-Italien ist informell informiert worden, dass seit ein paar Tagen erkennbar versucht wurde, die Daten massenhaft systematisch herunterzuladen. [...] Eine übliche Nutzung z.B. mit JOSM über die WMS-Extension ist natürlich erlaubt bzw. sogar gewünscht. Kann man ausschließen, daß so etwas mit JOSM versehentlich passiert? Angenommen, ich stelle eine hohe Auflösung ein, öffne ein WMS-Layer und zoome später weit raus. Versucht JOSM dann, die ganze Fläche in der hohen Auflösung zu laden? Wenn ja, ergibt das auch einen systematischen Massendownload. Wir haben über das PCN keine weiteren Details zu der Sache bekommen, ganz ausschließen kann ich das also nicht, aber es scheint, als wäre der Verursacher schon gefunden. Jemand hat wohl versucht, die Tiles zu cachen für die Benutzung in potlatch. Vermutlich ist damit die Sache erstmal erledigt (er wird das nicht weiterverfolgen und Potlatch 2.0 soll ja WMS auch nativ einbinden können). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohnmobil-Stellplätze bei OSM
Am 20. Mai 2010 14:28 schrieb Martin Mainzer mart...@gmx.de: das ist korrekt, ich habe der Einfachheit halber nicht alle tags verwendet, sondern nur diejenigen, die ich (subjektiv) für wichtig gehalten habe. Das sind: 'capacity', 'fee', 'power_supply' und 'tents'. Welche weiteren tags sind denn aus eurer Sicht noch wichtig und sollten auch noch aufgenommen werden? wie erwähnt wären m.E. Adressinformationen und Kontaktmöglichkeiten (tel, email, internetaddr.) sinnvoll, auch wenn gerade für letztere wohl kein Konsens besteht, dass sowas überhaupt eingetragen werden soll (wir sind ja kein Telefonbuch). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massendownloads vom PCN - portale geografico nazionale
da ich hier auch den Link zum PCN gepostet habe, ein kleiner Hinweis: Wie war denn das Betreff der Mail? -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massendownloads vom PCN - portale geografico nazionale
2010/5/21 Johann H. Addicks addi...@gmx.net: da ich hier auch den Link zum PCN gepostet habe, ein kleiner Hinweis: Wie war denn das Betreff der Mail? das weiss nur noch das Archiv, vermutlich sowas wie Luftbilder Italien oder so. Hier nochmal ein Link auf die italienische Seite mit den JOSM-Links: http://wiki.openstreetmap.org/wiki/WikiProject_Italy/PCN Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
Hi! Am 21.05.2010 13:59, schrieb aighes [via GIS]: Hallo, leider mochte er Comopser meine preparierte Datei nicht. Hast du eine Ahnung, wass da falsch gelaufen sein könnte? Klar. Negative IDs sind ungültig. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Inkonsistente-Kustenlinien-tp5082833p5085367.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massendownloads vom PCN - portale geografico nazionale
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.05.2010 18:49, schrieb M∡rtin Koppenhoefer: 2010/5/21 Johann H. Addicks addi...@gmx.net: Wie war denn das Betreff der Mail? das weiss nur noch das Archiv [...] Date: Wed, 5 May 2010 16:09:27 +0200 Message-ID: i2h7acdb3651005050709h6a80838av66f8461cd6953...@mail.gmail.com From: =?UTF-8?Q?M=E2=88=A1rtin_Koppenhoefer?= dieterdre...@gmail.com Subject: [Talk-de] 2 neue WMS in Italien -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv22iIACgkQnMz9fgzDSqdsnwCgkXXXke5zqnyp53ZOnxCDNqsv RbAAn2pDdpMPz+porO/nQl/WFk2gCJJx =00jY -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Falsche(?) hamlets
M∡rtin Koppenhoefer dieterdre...@gmail.com [Fri, May 21, 2010 at 02:10:03PM CEST]: Am 19. Mai 2010 16:11 schrieb René Falk li...@falconaerie.de: Die Gemeinde Bodolz daneben hat ebenfalls mehrere Ortsteile [2], doch sind manche nicht größer als ein Weiler. Wäre hier hamlet für alle Ortsteile die richtige Lösung? Hängt davon ab, wie es vor Ort ausschaut. Ist ein Ortsteil eher ein Dorf als ein Weiler, würde ich ihn auch als village taggen. Wenn der Ortsteil eher wie ein Weiler ausschaut, dann hamlet. +1, die manchen, die Weiler sind, als hamlet, und die die Dörfer sind als village. Genau, unabhängig davon, ob sie einer Stadt zugeordnet sind oder einer Samtgemeinde, einem Flecken oder sonstwas. Sag ich doch die ganze Zeit. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massendownloads vom PCN - portale geografico nazionale
Am 21.05.2010 21:08, schrieb Bodo Meissner: Wie war denn das Betreff der Mail? das weiss nur noch das Archiv Message-ID:i2h7acdb3651005050709h6a80838av66f8461cd6953...@mail.gmail.com Danke. Irgendwann werde ich mal einen Newsclient finden mit funktionsfähiger Volltext-Suche. (Nein, die vom Thunderbird3 ist broken...) -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM städtisch ausgelegt. Land braucht den cyclefootway
bkmap burkhard.kirch...@web.de writes: highway=path können sie ohnehin darstellen, auch wenn sie die Attribute noch nicht komplett auswerten. path ist im städtischen bereich völlig überflüssig und gegen den gesunden menschenverstand. Es macht die dinge nur unnötig kompliziert. Alle attribute kann man auch an die traditionellen highway-tags dranhängen (footway, cycleway, track). Also von mir ein klares NEIN zu cyclefootway oder ähnlichen Konstruktionen. Das hat ja auch niemand gefordert, jedenfalls niemand, der seine 7 sinne beisammen hat. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
