[OSM-talk] Welcome page to new users on wiki.openstreetmap.org
Hi, i just finished to welcome A* users in the wiki. i would like to welcome every single users without a userpage or without geographic category in it. Then i would like to have the newuser special page enabled to track new users registrations. Edoardo (EdoM) -- Edoardo Marascalchi ICT Consultant website: http://www.edoardomarascalchi.it skype: My status skype:asca_edom?call ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] Opentrail - What development environments would be best for mobile compatibility?
Not if you want to make a better map for OSM. Well, if your definition of better includes open, then no. I'm afraid that the number of people using iPhones will be quite small compared to normal phones, no matter how much you want it. Perhaps it's the £1000 you have to shell out. exactly. For phones: Exactly. If the application is aimed at the mass market / normal people, then go for what most phones have. java (j2me) If the application is aimed at techies then go for something that more techies are likely to have - possibly S60/90/python, and then you can leverage some increased technology but sacrifice numbers of users Just have a look at existing mobile phone software and see what they offer, the commercial efforts extend out with multiple formats to cover as many phones as possible, but they all seem to support j2me. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Mapnik rendering update
On Freitag 25 Januar 2008, Gervase Markham wrote: Jon Burgess wrote: There is a major update to the way tiles are rendered occurring at the moment, let me explain... snip Makes perfect sense. Thanks for the update, and your hard work. I look forward to seeing the shiny new map next Wednesday or so :-) A great thanks from Germany too !! -- Joerg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Large Rivers
Hi, is there anything going on withthe Large Rivers proposed feature? http://wiki.openstreetmap.org/index.php/Proposed_features/Large_rivers For the time being, how do I tag large water bodies? Like the Po river in North Italy or Rhine in Deutschland? Thanks, S. -- Simone Cortesi All that is gold does not glitter; not all those that wander are lost. J.R.R. Tolkien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Kosmos v1.9 - poster printing OSM maps
Hello everyone, As I promised a while back, Kosmos can now print OSM maps on multiple pages. For those interested more info is here: http://igorbrejc.net/openstreetmap/kosmos/kosmos-v19-printing-maps-inspecting-elements-and-more Cheers, Igor -- http://igorbrejc.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Kosmos v1.9 - poster printing OSM maps
Igor Brejc schrieb: Hello everyone, As I promised a while back, Kosmos can now print OSM maps on multiple pages. For those interested more info is here: http://igorbrejc.net/openstreetmap/kosmos/kosmos-v19-printing-maps-inspecting-elements-and-more Hi Igor! I just wanted to have a short look at the Kosmos source code, just out of interest. But I couldn't find it in the OSM svn or on your own pages. Funnily I found a LGPL lisense text together with the binaries, but not the sources. Am I just too blind to see? Regards, ULFL ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Kosmos v1.9 - poster printing OSM maps
Hi, As I promised a while back, Kosmos can now print OSM maps on multiple pages. For those interested more info is here: http://igorbrejc.net/openstreetmap/kosmos/kosmos-v19-printing-maps-inspecting-elements-and-more I've tried to play around with Kosmos; with no source code being available (hint, hint) I resorted to trying to run it under mono. The Kosmos.Gui.Exe application reports, rather unhelpfully: Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. --- System.Configuration.ConfigurationErrorsException: There is an error in a configuration setting. () () at System.Configuration.CustomizableFileSettingsProvider.LoadPropertyValue (System.Configuration.SettingsPropertyCollection collection, System.Configuration.SettingElement element, Boolean allowOverwrite) [0x0] at System.Configuration.CustomizableFileSettingsProvider.LoadProperies (System.Configuration.ExeConfigurationFileMap exeMap, System.Configuration.SettingsPropertyCollection collection, ConfigurationUserLevel level, System.String sectionGroupName, Boolean allowOverwrite) [0x0] at System.Configuration.CustomizableFileSettingsProvider.GetPropertyValues (System.Configuration.SettingsContext context, System.Configuration.SettingsPropertyCollection collection) [0x0] at System.Configuration.LocalFileSettingsProvider.GetPropertyValues (System.Configuration.SettingsContext context, System.Configuration.SettingsPropertyCollection properties) [0x0] at System.Configuration.ApplicationSettingsBase.CacheValuesByProvider (System.Configuration.SettingsProvider provider) [0x0] at System.Configuration.ApplicationSettingsBase.GetPropertyValue (System.String propertyName) [0x0] at System.Configuration.ApplicationSettingsBase.get_Item (System.String propertyName) [0x0] at Kosmos.Gui.Properties.Settings.get_MapFormLocation () [0x0] at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] --- End of inner exception stack trace --- (this was after I had fixed the \\ that appeared in the config file). So this doesn't seem to work. The CLI application starts up at least: Kosmos Console v1.9.27.2 by Igor Brejc OpenStreetMap rendering application USAGE: Kosmos command COMMANDS (choose one): tilegen Kosmos project file: generates tiles containing OSM map using the provided project file tileserv Kosmos project file: runs a web tile service -- how can I create a project file to try this out? Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Copyright and old maps
hi, Just to double check if this is OK. I found a collection of topo maps (1:250,000) of the Philippines from Uni of Texas' Library [http://www.lib.utexas.edu/maps/ams/philippines/]. As far as I understand, these are in the public domain [http://www.lib.utexas.edu/maps/faq.html#3.html] Ergo, I can use it for seeding some roads? cheers, maning On Jan 27, 2008 8:30 AM, Dominic Hargreaves [EMAIL PROTECTED] wrote: On Sat, Jan 26, 2008 at 07:03:40PM +, Gregory wrote: I was wondering about going to the local records office to look at old maps. Maybe use some to speed up an initial set of data for OSM (and building outlines which I can't get), and maybe just use some for interest to use on my website etc. http://wiki.openstreetmap.org/index.php/New_Popular_Edition might be of interest, if you don't already know about it. Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk -- |-|--| | __.-._ |Ohhh. Great warrior. Wars not make one great. -Yoda | | '-._7' |Freedom is still the most radical idea of all -N.Branden| | /'.-c |Linux registered user #402901, http://counter.li.org/ | | | /T |http://esambale.wikispaces.com| | _)_/LI |http://www.geocities.com/esambale/philbiodivmap/philbirds.html | |-|--| ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Arezzo
Hi, Some footage from the two days http://www.youtube.com/watch?v=WHNwCBqQHtY both from indoor and outdoor parts of the event ...sorry ;) no subtitles in English for this round, but you still may take a virtual tour of the town with Simone and Luca...or maybe take it as a good excuse to pick up some Italian (we'll be glad to provide translations) More news to follow - Regards, andrea, aka pibinko http://pibinko.altervista.org 2008/1/23, Simone Cortesi [EMAIL PROTECTED]: Hi, just a quick note to remember everybody that this coming weekend we are going to have our first Italian mapping party in beautiful Arezzo (Tuscany). http://wiki.openstreetmap.org/index.php/Arezzo_Mapping_Party Feel free to contact if you need any further information. Thanks, Simone. -- Simone Cortesi All that is gold does not glitter; not all those that wander are lost. J.R.R. Tolkien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] highway=stop
Gervase Markham wrote: Have these people not heard of Give Way/Yield or roundabouts? There are plenty of Yield and Roundabout intersections in the US. In fact, there are more (often unsigned) Yield intersections than any other type. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] highway=stop
Jo wrote: A stop sign is internationally a red octagonal sign with STOP written on it in white letters. It means that officially a full stop has to be made. In the US it's best to actually also do that, cause they are very strict about it. Not everywhere. There is a maneuver known as a 'California Stop' in which a driver at an intersection marked 'stop' slows to 5-10 mph, then continues through. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] highway=stop
On Jan 27, 2008 7:30 PM, Alex S. [EMAIL PROTECTED] wrote: Jo wrote: A stop sign is internationally a red octagonal sign with STOP written on it in white letters. It means that officially a full stop has to be made. In the US it's best to actually also do that, cause they are very strict about it. Not everywhere. There is a maneuver known as a 'California Stop' in which a driver at an intersection marked 'stop' slows to 5-10 mph, then continues through. That's a nasty rumor. ;-) It still means full stop, even in California. If you do that in front of an officer of the law, you will regret it... I've actually witnessed *bicyclists* ticketed for not stopping at a stop sign (on a dead still residential street, near the end of a 50 mile Multiple Sclerosis benefit ride, to boot). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Kosmos v1.9 - poster printing OSM maps
Hello Ulf, On Sun, Jan 27, 2008 at 11:27 PM, Ulf Lamping [EMAIL PROTECTED] wrote: Hi Igor! I just wanted to have a short look at the Kosmos source code, just out of interest. But I couldn't find it in the OSM svn or on your own pages. I haven't (yet) made Kosmos an open source project. I will publish the code on my download pages in the next few days. Funnily I found a LGPL lisense text together with the binaries, but not the sources. You are probably referring to the license file of the Flee library - a 3rd party library used in Kosmos for expression evaluation. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Kosmos v1.9 - poster printing OSM maps
Hello Frederik, On Mon, Jan 28, 2008 at 12:12 AM, Frederik Ramm [EMAIL PROTECTED] wrote: I've tried to play around with Kosmos; with no source code being available (hint, hint) I resorted to trying to run it under mono. The Kosmos.Gui.Exe application reports, rather unhelpfully: See my response to Ulf regarding the source code. As for running it in mono: I doubt it will run, unfortunately. An OSM user reported to me few weeks ago that he tried to run it in mono but Kosmos threw all sorts of exceptions. I tried to fix some of them, but then others appeared. I think the main problem is that Kosmos uses some stuff from .NET 2.0 which is not yet supported by mono. Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. --- System.Configuration.ConfigurationErrorsException: There is an error in a configuration setting. () () at System.Configuration.CustomizableFileSettingsProvider.LoadPropertyValue (System.Configuration.SettingsPropertyCollection collection, System.Configuration.SettingElement element, Boolean allowOverwrite) [0x0] at System.Configuration.CustomizableFileSettingsProvider.LoadProperies (System.Configuration.ExeConfigurationFileMap exeMap, System.Configuration.SettingsPropertyCollection collection, ConfigurationUserLevel level, System.String sectionGroupName, Boolean allowOverwrite) [0x0] at System.Configuration.CustomizableFileSettingsProvider.GetPropertyValues (System.Configuration.SettingsContext context, System.Configuration.SettingsPropertyCollection collection) [0x0] at System.Configuration.LocalFileSettingsProvider.GetPropertyValues (System.Configuration.SettingsContext context, System.Configuration.SettingsPropertyCollection properties) [0x0] at System.Configuration.ApplicationSettingsBase.CacheValuesByProvider (System.Configuration.SettingsProvider provider) [0x0] at System.Configuration.ApplicationSettingsBase.GetPropertyValue (System.String propertyName) [0x0] at System.Configuration.ApplicationSettingsBase.get_Item (System.String propertyName) [0x0] at Kosmos.Gui.Properties.Settings.get_MapFormLocation () [0x0] at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] --- End of inner exception stack trace --- (this was after I had fixed the \\ that appeared in the config file). So this doesn't seem to work. The CLI application starts up at least: This is not Kosmos' own exception - this part of the code is performed without the developer's control. It is thrown by mono when the main Kosmos forms is being created. The system tries to load user's preferences using the System.Configuration facility. I'm not sure this is supported by Mono. That '\\' is needed when running in Windows - log4net library expects double back slashes. I'll try to replace it with a single slash, I have to check if this works in log4net on Windows. Kosmos Console v1.9.27.2 by Igor Brejc OpenStreetMap rendering application USAGE: Kosmos command COMMANDS (choose one): tilegen Kosmos project file: generates tiles containing OSM map using the provided project file tileserv Kosmos project file: runs a web tile service -- how can I create a project file to try this out? Have you tried it with the sample project that comes with Kosmos? Regards, Igor ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Kosmos v1.9 - poster printing OSM maps
On Mon, Jan 28, 2008 at 1:40 AM, nyem [EMAIL PROTECTED] wrote: Igor, I get the following error with v1.9.27.2 when opening project files that are fine with previous versions. Kosmos Version: 1.9.27.2 OS Version: Microsoft Windows NT 5.1.2600 Service Pack 2 CLR Version: 2.0.50727.832 Current culture: English (United States) Current UI culture: English (United States) System.ArgumentException: An item with the same key has already been added. at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource) at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add) at OsmUtils.Framework.OsmDatabase.ImportData(osm osmData) in d:\MyStuff\BuildArea\Sandbox\OsmUtils\trunk\OsmUtils.Framework\OsmDatabase.cs:line 120 at Kosmos.Gui.Presenters.MapPresenter.AsyncReload(Object sender, DoWorkEventArgs e) Hmmm... can you give me some more info about the project file you are using? Do you use a single OSM file source or two or more? The exception thrown is not very helpful, I will try to add some exception handling here. regards, nyem ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk-nl] Twee nieuwe layers
Oh ja, wat cool!! Ben blij dat de OV-zones alsnog een plekje hebben gekregen. En mooi dat we nu een begin hebben van een NL-OSM in RD-coördinaten. Allemaal goede ontwikkelingen! Wat zijn de consequenties als je het tileschema gaat aanpassen? Veranderen de permalinks dan ook? Of is het alleen dat de server dan allemaal nieuwe tiles moet genereren? Als dat laatste zo is dan moeten we het even goed afstemmen met het uitsturen van een persbericht. Het carnavalsbericht kan echt niet meer wachten omdat carnaval dit jaar zo vroeg wordt gevierd (begint al 3 feb). Ik zou zeggen dat het persbericht er zeker deze week uit moet. Martijn Op 27 jan 2008, om 08:43 heeft Martijn van Oosterhout het volgende geschreven: Er zijn vandaag twee nieuwe layers aangemaakt: 1. Eentje met de OV zones. Graag feedback over kleuren/font/size/etc. Dit is een overlay, kan je over elke andere layer doen. 2. De lang verwachte (sinds, eh, 3 dagen) carnavals layer. Ziet er redelijk uit geloof ik. Ik wil een deze dagen wat veranderingen maken (vooral de tile nummers) maar dat is niet handig als er net een pers bericht de deur uit is. Wanneer zou dit het handigst zijn? Mvg, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Twee nieuwe layers
On Jan 27, 2008 9:37 AM, Martijn van Exel [EMAIL PROTECTED] wrote: Wat zijn de consequenties als je het tileschema gaat aanpassen? Veranderen de permalinks dan ook? Of is het alleen dat de server dan allemaal nieuwe tiles moet genereren? De permalinks veranderen niet, alleen de nummers van de tiles worden dan hetzelvde als de main server en nog balangerijker, de grid is dan ook hetzelvde, dus kan je tiles van de twee naast mekaar zetten. Tiles moeten wel gegenereerd worden, maar dat doet ie toch elke paar dagen. Het carnavalsbericht kan echt niet meer wachten omdat carnaval dit jaar zo vroeg wordt gevierd (begint al 3 feb). Ik zou zeggen dat het persbericht er zeker deze week uit moet. Nou, dan wacht ik wel. Als alles goed gaat merk je er niks van, maar je moet altijd plannen voor als het mis gaat. Mvg, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Carnaval - losse eindjes
Ik kon effe zo snel niet vinden hoe ik 'm zelf moest toevoegen, maar in Zeeland is één katholiek bolwerk(je) waar écht gecarnavalt wordt: 's Heerenhoek heet in deze periode Paerehat Martijn van Exel schreef: Ha, Voordat we het carnavalspersbericht (wie?) de deur uit kunnen doen moeten er volgens mij nog twee dingen gebeuren: * carnaval.openstreetmap.nl laten verwijzen naar een permalink (bijvoorbeeld http://tile.openstreetmap.nl/?zoom=10lat=51.52361lon=5.44632layers=0B0F ) - indien mogelijk (Jeroen?). * 'iets' regelen voor het melden van aanvullingen / fouten in de carnavalsnaamgeving. Hiervoor zijn al de revue gepasseerd: * topic op forum (nadeel: registreren vereist) * wikipagina (nadeel: registreren vereist) * rechtstreeks op de kaart klikken (maar dat moet eerst geïmplementeerd worden) * op de zojuist aangemaakte Hyve ;) [1] -- Dit is misschien nog wel de kortste klap - wie is er nu niet op Hyves tegenwoordig? Wat denken jullie ervan? [1] http://openstreetmap.hyves.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Carnaval Definitief
Wanneer kunnen we carnaval.openstreetmap.nl verwachten? Het zou ontzettend mooi zijn als ik in het persbericht over de Friese layer vermelding kan maken van http://frysk.openstreetmap.nl. Het heeft niet alleen een estetische waarde maar ook technische. Aangezien de layer naam in de permalink gebonden is aan de volgorde van de layers in OL en niet van de kaart zelf kan het toevoegen van een nieuwe layer dus tot gevolg hebben dat een permalink niet meer werkt (de permalink verwijst dan naar een andere layer). Kan iemand die een direct lijntje heeft met Jeroen deze gebruiken en proberen dit voor elkaar te krijgen (voor carnaval natuurlijk ook)? ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] Assen
Dag Richard en Henk, Tijdens het volgen van een GPX kruimelspoortje in JOSM kwam ik in Assen uit alwaar ik ontdekte dat nogal wat fietspaden (door de AND import?) verminkt zijn. Er zijn stukken (tussenuit) verdwenen en op kruispunten zijn de fietspaden niet met de kruisende wegen verbonden. Ik heb een paar punten langs mijn route gerepareerd maar ik wilde het jullie even laten weten aangenzien dit jullie backyard is. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Carnaval Definitief
We hebben nu in ieder geval meer dan alleen de kaart van Brabant, maar of we de 95% van hun halen, ik vraag het me af. Ik wil die andere plekken wel afstruinen, zo moeilijk kan die 20% niet zijn ;) Op 5% na zijn ze dit allemaal, de rest is niet te vinden in de osm database, een aantal zijn wijken van steden, of maar een gedeelte of combo van een stad/dorp die zo niet in de db staan. Ik zelf zou niet weten hoe we dit op de kaart krijgt dus als iemand deze lijst nog ergens door wil halen om de boel up te daten zou dat super zijn. 60400458,city,#38,apos,s-Hertogenbosch,Oeteldonk 44196313,village,#39,s-Heerenberg,Waskuupstad 42666235,village,#39,s-Heerenhoek,Paerehat 42535312,village,Aalst,Ballengat 42287984,village,Aardenburg,'t Uulehat 42857683,village,Aarle-Rixtel,Ganzegat 45414873,village,Achterveld,Puupenkoppenland 42672131,village,Achtmaal,Goudpoeperslaand 44283711,village,Aerdt,Spreeuwendurp 46395647,village,Albergen,Bökkenlaand 43845348,village,Alem,Spreeuwendurp 42751438,village,Alphen,Struivenlaand 45398103,town,Alphen aan den Rijn,Het Rijk van Castellum 42622646,village,America,Turftreiersriek 45488182,city,Amersfoort,Trekkersgat 43735675,village,Ammerzoden,Malse Arckeldurp 46097453,town,Amstelveen,'t Turvegat 44381560,village,Angeren,Keujesgat 45951968,village,Ankeveen,Schuimlikkerveen 216244216,city,Apeldoorn,Knienenburg 42731455,village,Arcen,Keieschietersriek 42547976,village,Asten,Klotland 42638466,village,Baarle-Nassau,Smokkelgat 42381488,village,Baarlo,Kôôke-riék 42224166,village,Baexem,Plekploasterland 42827302,village,Bakel,Pierewaaiersrijk 47362257,village,Barger-Compascuum,Stiekelstad 45438365,town,Barneveld,Kiependaarp 45887945,village,Bathmen,Pompersgat 43046865,village,Bavel,Baviaonenland 42962318,village,Beek en Donk,Ganzendonk 42278227,village,Beesel,Drakeriék 42339358,village,Belfeld,Belhamelriëk 44212662,village,Beneden-Leeuwen,Lauwe 43983700,village,Berg en Dal,Duufelshemel 42355131,village,Bergeijk,Teutengat 42776312,town,Bergen op Zoom,Krabbegat 44087004,village,Bergharen,Wurmensoppersrijk 43798974,village,Berghem,Knollenrijk 43132701,village,Berkel-Enschot,Knollevretersgat 43476837,village,Berlicum,Dun Birrekoal 42826877,town,Best,Klompengat 44116743,town,Beuningen,Eikelenburg 42466157,village,Bladel,Muggeziftersrijk 43198064,village,Boekel,Knöllekesland 43252496,village,Borne,Melbuul'ndorp 46118669,village,Bornerbroek,Knoll'nbrook 46202337,village,Boskamp,Toetlipp'ndarp 45128961,village,Boskoop,Kwakveen 43032924,village,Bosschenhoofd,Smoorfrèterslaand 43168864,town,Boxtel,Eendengat 44420285,village,Braamt,Nottedarp 43139322,city,Breda,Kielegat 42286422,village,Budel,Bokkenrijk 42239616,village,Budel-Dorplein,Heiknuuterland 42252111,village,Budel-Schoot,Toeterland 45097897,village,Bunnik,Kikkerloo 45990885,town,Bussum,Erwtenrijk 43535508,village,Capelle,Cuppelsgat 42533302,village,Casteren,Bollenmeppersgat 46910561,town,Castricum,Pieperduin 42838224,village,Chaam,Bonenpikkerslaand 42277795,village,Clinge,Kriekedorp 44793343,village,Cothen,Brienkneuterdorp 43414914,village,Cromvoirt,Kneutergat 43688088,town,Cuijk,Nolersriek 44545426,town,Culemborg,Papklokkendam 46141431,village,De Lutte,Tuffellaand 42963454,village,De Mortel,Krulstarteland 47002714,village,Dedemsvaart,Kloetendonk 44257741,village,Deest,Het Golvenrijk 43224240,village,DeHeen,Strienedurpke 45931506,village,Delden,Kwekwestad 44817952,town,Delft,Kabbelgat 44678996,village,DeLier,Bukkersgat 43266091,village,DeMoer,Moerbiënlaand 45155630,city,Den Haag,Kreesiedentie 47668194,town,Den Helder,Waaienburg 43402259,village,Den Hout,Kluivenduikersrijk 43434808,village,DenDungen,Krabberdonk 46417470,town,Denekamp,Köttelpeer'ndoarp 42998036,village,DeRips,Streupersrijk 42689402,town,Deurne,Peelstrekelrijk 46091623,village,Deurningen,Nettelkörnkesnust 45924949,town,Deventer,Stokvissengat 45037448,town,Dieren,Zwieren 42719810,village,Diessen,Stopnaoldenrijk 43303951,village,Dinteloord,Peejlòòfdurp 42102750,village,Doenrade,Gruuëtsje Gekke Rieëk 44645727,town,Doetinchem,Leutekum 43269861,town,Dongen,Peejenrijk 44260943,village,Doornenburg,'t Woatergoat 43863172,city,Dordrecht,Ooi- en Ramsgat 43153000,village,Dorst,Kattegat 45033881,town,Driebergen Rijsenburg,Sparrenrijck 44600016,village,Driel,Uulenes 43512320,town,Drunen,Dwergonië 44237820,village,Druten,Bokkenrijk 42484690,village,Duizel,Zwetsgat 43668738,village,Dussen,Klayendam 42146250,village,Echt,Aesterriek 46807422,town,Edam,Sufbrugge 45242010,village,Eerbeek,Dwarsliggerdorp 43202742,village,Eerde,Oiverland 42458294,village,Eersel,Buurtgat 42616340,city,Eindhoven,Lampegat 43103296,village,Elsendorp,Peelvruutersrijk 42833523,village,Elshout,Zaandhaozenlaand 44378712,town,Elst,Döppertdurp 47254785,town,Emmeloord,Pierenoord 43662018,village,Empel,Slotgat 43651611,village,Engelen,Terpersdurp 47055997,village,Ens,Kleiduikersland 45753522,city,Enschede,Krekkelstad 46278640,town,Epe,Grolle 43193517,village,Erp,Empeldonk 42691739,village,Esbeek,Haaikneuterrijk
Re: [OSM-talk-nl] Carnaval Definitief
Ok, bedankt voor de info. Helaas werkt de URL nog niet zoals het moet zijn. De URL wijst naar de default layer (NL). Het zou ontzettend mooi zijn als ik in het persbericht over de Friese layer vermelding kan maken van http://frysk.openstreetmap.nl. FWIW, voor frysk.tile.openstreetmap.nl en carnaval.tile.openstreetmap.nl hebben wij Jeroen niet nodig, die doen het gewoon. Minder mooi, maar werkt wel... ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Twee nieuwe layers
het zou ook mooi zijn als je nog een srtm base layer erbij kon hebben alleen werkt dat natuurlijk niet samen met je huidige base layers ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Carnaval Definitief
On Sun, 27 Jan 2008, Stefan de Konink wrote: joris meijerink schreef: We hebben nu in ieder geval meer dan alleen de kaart van Brabant, maar of we de 95% van hun halen, ik vraag het me af. Ik wil die andere plekken wel afstruinen, zo moeilijk kan die 20% niet zijn ;) Op 5% na zijn ze dit allemaal, de rest is niet te vinden in de osm database, een aantal zijn wijken van steden, of maar een gedeelte of combo van een stad/dorp die zo niet in de db staan. Ik zelf zou niet weten hoe we dit op de kaart krijgt dus als iemand deze lijst nog ergens door wil halen om de boel up te daten zou dat super zijn. Leidschendam, Stompwijk zie ik beide niet meer op de kaart staan. Respectievelijk Zwabberdam en Gaandrie. ...Het lijkt er op dat na mijn vorige berichtje over de Sijtwende tunnel Leidschendam en Voorburg compleet van de kaart zijn geveegd. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Carnaval Definitief
joris meijerink schreef: We hebben nu in ieder geval meer dan alleen de kaart van Brabant, maar of we de 95% van hun halen, ik vraag het me af. Ik wil die andere plekken wel afstruinen, zo moeilijk kan die 20% niet zijn ;) Op 5% na zijn ze dit allemaal, de rest is niet te vinden in de osm database, een aantal zijn wijken van steden, of maar een gedeelte of combo van een stad/dorp die zo niet in de db staan. Ik zelf zou niet weten hoe we dit op de kaart krijgt dus als iemand deze lijst nog ergens door wil halen om de boel up te daten zou dat super zijn. Leidschendam, Stompwijk zie ik beide niet meer op de kaart staan. Respectievelijk Zwabberdam en Gaandrie. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Carnaval Definitief
2008/1/27 Lambertus [EMAIL PROTECTED]: Ok, bedankt voor de info. Helaas werkt de URL nog niet zoals het moet zijn. De URL wijst naar de default layer (NL). Ik zei dat het zou kunnen, niet dat het al werkt. Als mensen het ok vinden zal ik het priberen te regelen. Mvg, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Carnaval - losse eindjes
Voordat we het carnavalspersbericht (wie?) de deur uit kunnen doen moeten er volgens mij nog twee dingen gebeuren: Een persbericht lijkt meer iets voor iemand die wat meer heeft met carnaval. Ik vind het erg leuk de info bij elkaar te zoeken maar een persbericht is toch even iets anders. * carnaval.openstreetmap.nl laten verwijzen naar een permalink (bijvoorbeeld http://tile.openstreetmap.nl/?zoom=10lat=51.52361lon=5.44632layers=0B0F ) - indien mogelijk (Jeroen?). * 'iets' regelen voor het melden van aanvullingen / fouten in de carnavalsnaamgeving. Hiervoor zijn al de revue gepasseerd: * topic op forum (nadeel: registreren vereist) * wikipagina (nadeel: registreren vereist) * rechtstreeks op de kaart klikken (maar dat moet eerst geïmplementeerd worden) * op de zojuist aangemaakte Hyve ;) [1] -- Dit is misschien nog wel de kortste klap - wie is er nu niet op Hyves tegenwoordig? Waarom zelf een lijst aanleggen? Lijkt me praktischer gewoon de wikipediasite layout een beetje aan te passen zodat we er makkelijker mee overweg kunnenhttp://nl.wikipedia.org/wiki/Lijst_van_Nederlandse_plaatsnamen_tijdens_carnaval). Dan wordt de data aangevuld door zowel mensen die voor de kaart bezig zijn als mensen die gewoon op wikipedia langs komen en hun stad/dorp willen toevoegen, dan krijgen we eerder een volledige (meer complete) lijst. Ander voordeel is dat je je niet hoeft aan te melden om te kunnen wijzigen. Ook kost het maken van een lijst minder moeite dan het uit moeten zoeken van een hele lijst met entries in een of ander gastenboek/berichten lijst. Wat denken jullie ervan? dat dus ;) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] Fixme: Leidschendam-Voorburg
- Plaatsnamen zijn in Mapnik verdwenen - Sijtwende trace is verdwenen - Stompwijk staat niet meer op de kaart ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Carnaval - losse eindjes
Ik geloof wel dat Wikipedia een goede plek is om de Carnavalsnamen van plaatsen bij te houden in algemene zin, daar hoeven wij geen aparte lijst van bij te houden, daar ben ik het helemaal mee eens. Schoenmaker blijf bij de leest. Maar nu hebben wij een Carnavalskaart gemaakt, en als daar straks ruchtbaarheid aan wordt gegeven dan wil je dat mensen die gaan kijken ook meteen worden geconfronteerd met het open karakter van de kaart: klopt er iets niet? Ontbreekt er iets? Vul zelf aan! Het forum dat ik voor ogen zie is dan ook zuiver bedoeld om zoveel mogelijk mensen in staat te stellen om mee te discussiëren over de OSM-carnavalskaart, bij gebrek aan een mogelijkheid om rechtstreeks in de kaart bij te werken. Als je bezoekers verwijst naar een Wiki die niets met OSM te maken heeft, dan wordt het volgens mij niet duidelijk dat je als gebruiker rechtstreeks invloed kunt uitoefenen op de kaart. -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ Op 27 jan 2008, om 14:59 heeft joris meijerink het volgende geschreven: Voordat we het carnavalspersbericht (wie?) de deur uit kunnen doen moeten er volgens mij nog twee dingen gebeuren: Een persbericht lijkt meer iets voor iemand die wat meer heeft met carnaval. Ik vind het erg leuk de info bij elkaar te zoeken maar een persbericht is toch even iets anders. * carnaval.openstreetmap.nl laten verwijzen naar een permalink (bijvoorbeeld http://tile.openstreetmap.nl/?zoom=10lat=51.52361lon=5.44632layers=0B0F ) - indien mogelijk (Jeroen?). * 'iets' regelen voor het melden van aanvullingen / fouten in de carnavalsnaamgeving. Hiervoor zijn al de revue gepasseerd: * topic op forum (nadeel: registreren vereist) * wikipagina (nadeel: registreren vereist) * rechtstreeks op de kaart klikken (maar dat moet eerst geïmplementeerd worden) * op de zojuist aangemaakte Hyve ;) [1] -- Dit is misschien nog wel de kortste klap - wie is er nu niet op Hyves tegenwoordig? Waarom zelf een lijst aanleggen? Lijkt me praktischer gewoon de wikipediasite layout een beetje aan te passen zodat we er makkelijker mee overweg kunnenhttp://nl.wikipedia.org/wiki/Lijst_van_Nederlandse_plaatsnamen_tijdens_carnaval) . Dan wordt de data aangevuld door zowel mensen die voor de kaart bezig zijn als mensen die gewoon op wikipedia langs komen en hun stad/dorp willen toevoegen, dan krijgen we eerder een volledige (meer complete) lijst. Ander voordeel is dat je je niet hoeft aan te melden om te kunnen wijzigen. Ook kost het maken van een lijst minder moeite dan het uit moeten zoeken van een hele lijst met entries in een of ander gastenboek/berichten lijst. Wat denken jullie ervan? dat dus ;) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Carnaval Definitief
Ok, bedankt voor de info. Helaas werkt de URL nog niet zoals het moet zijn. De URL wijst naar de default layer (NL). Ik zei dat het zou kunnen, niet dat het al werkt. Als mensen het ok vinden zal ik het priberen te regelen. Dan heb ik je niet goed begrepen want zo las ik het wel. Maargoed, als er één oplossing die stabiele permalinks kan opleveren dan ben ik al blij. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Carnaval Definitief
Hallo Martijn, misschien kun je iets met het volgende stukje httpd.conf: VirtualHost *:80 ServerName http://carnaval.tile.openstreetmap.nl/ ErrorLog logs/carnaval-error_log CustomLog logs/carnaval-access_log common DocumentRoot /var/www/carnaval/html/ Directory /var/www/carnaval/html Options +Indexes +FollowSymLinks AllowOverride All Order allow,deny Allow from all /Directory /VirtualHost In /var/www/carnaval/html/ een aangepaste index.html met als base layer carnaval. Idem kan dan natuurlijk ook voor frysk.. Martijn van Oosterhout schreef: 2008/1/27 Lambertus [EMAIL PROTECTED]: Ok, bedankt voor de info. Helaas werkt de URL nog niet zoals het moet zijn. De URL wijst naar de default layer (NL). Ik zei dat het zou kunnen, niet dat het al werkt. Als mensen het ok vinden zal ik het priberen te regelen. Mvg, Als frysk.openstreetmap.nl en carnaval.tile.openstreetmap.nl een alias worden voor tile.openstreetmap.nl kan het ook gebruikt worden. Groeten, Peter. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Carnaval - losse eindjes
Ik geloof wel dat Wikipedia een goede plek is om de Carnavalsnamen van plaatsen bij te houden in algemene zin, daar hoeven wij geen aparte lijst van bij te houden, daar ben ik het helemaal mee eens. Schoenmaker blijf bij de leest. Maar nu hebben wij een Carnavalskaart gemaakt, en als daar straks ruchtbaarheid aan wordt gegeven dan wil je dat mensen die gaan kijken ook meteen worden geconfronteerd met het open karakter van de kaart: klopt er iets niet? Ontbreekt er iets? Vul zelf aan! Het forum dat ik voor ogen zie is dan ook zuiver bedoeld om zoveel mogelijk mensen in staat te stellen om mee te discussiëren over de OSM-carnavalskaart, bij gebrek aan een mogelijkheid om rechtstreeks in de kaart bij te werken. Als je bezoekers verwijst naar een Wiki die niets met OSM te maken heeft, dan wordt het volgens mij niet duidelijk dat je als gebruiker rechtstreeks invloed kunt uitoefenen op de kaart. Ja ok, daar zit ook weer wat in. Dan zou ik naast een forum toch wel een eigen lijst gaan bijhouden, dan kunnen we daar ook meer info in kwijt op een manier waarmee we dan met een muisklik of twee een naam aan de kaart kunnen toevoegen en de kaart kunnen updaten. Is het mogelijk met een klik op de kaart het node id van een stad op te vragen? Dat zou het een en ander heel makkelijk maken en dat is dan een lijst waar ze op de normale wiki ook niks aan hebben wat een eigen lijst zou rechtvaardigen. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] Persbericht OpenStreetMap maakt gratis kaart in de Friese taal
Zo, het kost de mens een paar grijze haren maar het is gelukt. Onderstaand de concept tekst, graag commentaar. Buiten de Friese media (LC, FD, OF) en ons blog, welke media zullen we hierme verblijden? =PERSBERICHT= 27 januari 2008, OpenStreetMap maakt gratis kaart in de Friese taal OpenStreetMap presenteert een Friestalige versie van haar gratis digitale kaart. Deze kaart, waarop de Friese benamingen van o.a. plaatsen, straten en meren worden weergegeven, is het resultaat van het werk van enthousiaste vrijwilligers uit de OpenStreetMap gemeenschap. Door het ontbreken van commerciële belangen en het open karakter is het mogelijk om actief te zijn op gebieden die door de traditionele kaartenmakers niet interessant gevonden worden. Een mooi voorbeeld hiervan is de Friestalige kaart, aldus een woordvoerder van OpenStreetMap. Voor zover wij weten is dit een unicum: er was tot nu toe geen Friestalige digitale kaart van Nederland. OpenStreetMap ontketent de wereldkaart zoals Wikipedia de encyclopedie heeft ontketend. Ons doel: een vrij beschikbare wereldkaart waaraan iedereen kan meewerken. Ontstaan in Engeland in 2004 heeft OpenStreetMap in de afgelopen jaren wereldwijd vrijwilligers enthousiast gemaakt om gewapend met GPS en notitieblok de vrije wereldkaart steeds beter en completer te maken. De OpenStreetMap gemeenschap is zich ervan bewust dat de kaart in de Friese taal altijd beter kan en roept daarom geïnteresseerden op om mee te werken aan een nog betere kaart. Zie voor meer informatie: http://www.openstreetmap.nl De kaart in de Friese taal is te bekijken op: http://frysk.tile.openstreetmap.nl =EINDE PERSBERICHT= ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Persbericht OpenStreetMap maakt gratis kaart in de Friese taal
Dat gaat mij niet lukken...Spreken prima, schrijven niet. Misschien dat Gerko-Kees een poging kan doen? From: Stefan de Konink Lambertus schreef: Zo, het kost de mens een paar grijze haren maar het is gelukt. Onderstaand de concept tekst, graag commentaar. Buiten de Friese media (LC, FD, OF) en ons blog, welke media zullen we hierme verblijden? Ik zou als je een persbericht maakt, het zeker ook in het Fries schrijven, daarmee krijg je veel sneller aandacht in de lokale media. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Persbericht OpenStreetMap maakt gratis kaart in de Friese taal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Lambertus schreef: Zo, het kost de mens een paar grijze haren maar het is gelukt. Onderstaand de concept tekst, graag commentaar. Buiten de Friese media (LC, FD, OF) en ons blog, welke media zullen we hierme verblijden? Ik zou als je een persbericht maakt, het zeker ook in het Fries schrijven, daarmee krijg je veel sneller aandacht in de lokale media. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHnOCQYH1+F2Rqwn0RCj/fAJ9iwyUuloKiJ0US89KRzqm/kuIvLQCeJllM y3xTrhnvym7QT0UCE8zy5C4= =+Y9N -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Persbericht OpenStreetMap maakt gratis kaart in de Friese taal
Door het ontbreken van commerciële belangen en het open karakter is het mogelijk om actief te zijn op gebieden die door de traditionele kaartenmakers niet interessant gevonden worden. Een mooi voorbeeld hiervan is de Friestalige kaart, aldus een woordvoerder van OpenStreetMap. Voor zover wij weten is dit een unicum: er was tot nu toe geen Friestalige digitale kaart van Nederland. Goed punt, alleen mis ik een bruggetje om hier te komen. Misschien kun je eerst aangeven dat zo'n kaart nog niet eerder bestond. Daarna uitleggen waarom (commercieel niet interessant). OpenStreetMap ontketent de wereldkaart zoals Wikipedia de encyclopedie heeft ontketend. Ons doel: een vrij beschikbare wereldkaart waaraan iedereen kan meewerken. Ontstaan in Engeland in 2004 heeft OpenStreetMap in de afgelopen jaren wereldwijd vrijwilligers enthousiast gemaakt om gewapend met GPS en notitieblok de vrije wereldkaart steeds beter en completer te maken. Lijkt me meer een alinea voor helemaal onderaan. En vanuit derde persoon schrijven ivm consistentie. De OpenStreetMap gemeenschap is zich ervan bewust dat de kaart in de Friese taal altijd beter kan en roept daarom geïnteresseerden op om mee te werken aan een nog betere kaart. Zie voor meer informatie: http://www.openstreetmap.nl Nog aangeven dat het eenvudig is om bij te dragen? Zorg ervoor dat ze op de url 'opgevangen' worden en direct verder kunnen. Je blogpost staat niet altijd bovenaan. De kaart in de Friese taal is te bekijken op: http://frysk.tile.openstreetmap.nl - kan title aangepast worden? (Fryske kaart ipv NL tileserver) - de overlay met uitleg, kan die specifiek voor Frysk? En ook in het Fries? Kort wat het is, en url naar uitleg hoe verbeteringen doorgevoerd kunnen worden. - (algemener) kan er een CC logo op? =EINDE PERSBERICHT= Zet er nog even je contactgegevens (mail/tel) onder. En ja, zeker ook in het Fries (laten) vertalen! Groet, Zoran ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Persbericht OpenStreetMap maakt gratis kaart in de Friese taal
Ok, bedankt, dit zijn goede opmerkingen. Ik ga ermee aan de slag. From: Zoran Kovacevic Door het ontbreken van commerciële belangen en het open karakter is het mogelijk om actief te zijn op gebieden die door de traditionele kaartenmakers niet interessant gevonden worden. Een mooi voorbeeld hiervan is de Friestalige kaart, aldus een woordvoerder van OpenStreetMap. Voor zover wij weten is dit een unicum: er was tot nu toe geen Friestalige digitale kaart van Nederland. Goed punt, alleen mis ik een bruggetje om hier te komen. Misschien kun je eerst aangeven dat zo'n kaart nog niet eerder bestond. Daarna uitleggen waarom (commercieel niet interessant). OpenStreetMap ontketent de wereldkaart zoals Wikipedia de encyclopedie heeft ontketend. Ons doel: een vrij beschikbare wereldkaart waaraan iedereen kan meewerken. Ontstaan in Engeland in 2004 heeft OpenStreetMap in de afgelopen jaren wereldwijd vrijwilligers enthousiast gemaakt om gewapend met GPS en notitieblok de vrije wereldkaart steeds beter en completer te maken. Lijkt me meer een alinea voor helemaal onderaan. En vanuit derde persoon schrijven ivm consistentie. De OpenStreetMap gemeenschap is zich ervan bewust dat de kaart in de Friese taal altijd beter kan en roept daarom geïnteresseerden op om mee te werken aan een nog betere kaart. Zie voor meer informatie: http://www.openstreetmap.nl Nog aangeven dat het eenvudig is om bij te dragen? Zorg ervoor dat ze op de url 'opgevangen' worden en direct verder kunnen. Je blogpost staat niet altijd bovenaan. De kaart in de Friese taal is te bekijken op: http://frysk.tile.openstreetmap.nl - kan title aangepast worden? (Fryske kaart ipv NL tileserver) - de overlay met uitleg, kan die specifiek voor Frysk? En ook in het Fries? Kort wat het is, en url naar uitleg hoe verbeteringen doorgevoerd kunnen worden. - (algemener) kan er een CC logo op? =EINDE PERSBERICHT= Zet er nog even je contactgegevens (mail/tel) onder. En ja, zeker ook in het Fries (laten) vertalen! Groet, Zoran ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Persbericht OpenStreetMap maakt gratis kaart in de Friese taal
Hoi, De kaart in de Friese taal is te bekijken op: http://frysk.tile.openstreetmap.nl Is zo'n soort URL er ook voor de carnavals-layer (ik heb niet gezocht, zou kunnen...) Mag ik je stukje over Friesland zoek/vervangen door carnaval en en naar _mijn_ lokale pers rondsturen? Het kan nog net, zeg maar... Christ van Willegen (vanuit Lampegat) -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
wobei ich feststelle, dass im Gegensatz zu den Beispieltracks meine anderen Tracks nur noch als Weiße Flächen auf hellgrauem Grund erscheinen: http://informationfreeway.org/?lat=48.99602671126077lon=8.27852014461402zoom=16layers=B000F000F Kann man herausbekommen (und gegebenenfalls fixen) warum denen die gestrichelten Linien fehlen? Das passiert imo, wenn ein tracktype nicht richtig gesetzt ist, z.b. grade 1 Bei mir scheint es noch nicht 100% zu funktionieren, manche tracks werden bereits mit dem neuem Patch gerendert, manche nicht, versteh ich nicht ganz. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
Gernot Hillier schrieb: Hi! John07 schrieb: Kann man herausbekommen (und gegebenenfalls fixen) warum denen die gestrichelten Linien fehlen? Das passiert imo, wenn ein tracktype nicht richtig gesetzt ist, z.b. grade 1 Bei mir scheint es noch nicht 100% zu funktionieren, manche tracks werden bereits mit dem neuem Patch gerendert, manche nicht, versteh ich nicht ganz. Osmarender? Wenn ja, dann liegt das vielleicht an der verteilten Natur von Osmarender. Mancher, der das [EMAIL PROTECTED] unterstützt, aktualisiert wohl regelmäßig die Renderregeln, andere nicht. Es gibt wohl ab und an Major-Updates, die dafür sorgen, dass alte Renderer nicht mehr unterstützt werden, aber für die Feinheiten dazwischen macht man das wohl nicht. Ja, Osmarender. Deine Theorie klingt plausibel :-) Es erklärt auch, warum die neue Darstellung schon mal da war und nach erneutem Rendern wieder weg. Immerhin weiß ich jetzt bescheid, dass es nicht an mir liegt. Dann bleibt mir wohl nichts anderes übrig als abzuwarten. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
Moin, G - so sieht der Modellflugplatz aber mit Sicherheit nicht aus den Du mit dort hin mappen wolltest! ;-) jaja, Du sollst Deinen Modellflugplatz schon noch bekommen. Aber erst wenn die Fähre wieder fährt :) . Cheers, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
Moin, Das passiert imo, wenn ein tracktype nicht richtig gesetzt ist, z.b. grade 1 das güldene Hasenhürn des Monats geht an mich. tracktype=1 statt tracktype=grade1. Keine Ahnung was ich mir da gestern bei gedacht habe. Beste Grüße, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
On Sat, 26 Jan 2008 16:07:12 +0100 Christoph Eckert [EMAIL PROTECTED] wrote: Hi, Ich als Radfahrer finde es OK, dass Grade1 fast wie serive aussieht. Ich könnte mir aber vorstellen, dass Inlineskater sich wünschen würden, auf der Karte einen deutlichen Unterschied zu sehen. Vielleicht könnte man grade1 so behandeln wie die tracks bisher auch und von dort aus Abstufungen durchführen. Kann osmarender eigentlich mit SVG-Transparenzen umgehen? Vielleicht könnte man ja auf diese Weise eine Abstufung erreichen. Also moment mal, was soll denn jetzt ein track mit grade1 sein? Also wenn das asphaltierte Wege sein sollen (paved), die sich von den service-Wegen nur durch den Hauptverwendungszweck unterscheiden, dann sehe ich da gerade nicht den Grund warum sich das so beim Rendern unterscheiden sollte. Immerhin sind das auch die Wege, auf denen mir die meisten Inlineskater begegnen. MfG Andreas Kemnade ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
Hi! John07 schrieb: Kann man herausbekommen (und gegebenenfalls fixen) warum denen die gestrichelten Linien fehlen? Das passiert imo, wenn ein tracktype nicht richtig gesetzt ist, z.b. grade 1 Bei mir scheint es noch nicht 100% zu funktionieren, manche tracks werden bereits mit dem neuem Patch gerendert, manche nicht, versteh ich nicht ganz. Osmarender? Wenn ja, dann liegt das vielleicht an der verteilten Natur von Osmarender. Mancher, der das [EMAIL PROTECTED] unterstützt, aktualisiert wohl regelmäßig die Renderregeln, andere nicht. Es gibt wohl ab und an Major-Updates, die dafür sorgen, dass alte Renderer nicht mehr unterstützt werden, aber für die Feinheiten dazwischen macht man das wohl nicht. Ich bin hier in der Gegend auch schier verzweifelt, weil bei mehreren hintereinanderliegenden Brücken die Brückeneigenschaft manchmal gerendert wurde und manchmal nicht. Habe alles mögliche probiert, um den herauszufinden, warum, bis ich es eines Tages aufgegeben habe. Und siehe da, eine Woche später waren plötzlich alle Brücken da. Ich vermute also, dass einfach irgendwer noch einen veralteten Stand des Renderers laufen hatte... -- Gernot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
Moin, du bist nicht allein, siehe Statistik zu tracktype http://etricceline.de/osm/germany/de_stats_tracktype.htm mag sein, aber ich bin schon so lange dabei dass mir solche Schnitzer eigentlich nicht passieren sollten. Gruß Dank, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
Hallo, du bist nicht allein, siehe Statistik zu tracktype http://etricceline.de/osm/germany/de_stats_tracktype.htm Gruß Thomas Christoph Eckert schrieb: Moin, Das passiert imo, wenn ein tracktype nicht richtig gesetzt ist, z.b. grade 1 das güldene Hasenhürn des Monats geht an mich. tracktype=1 statt tracktype=grade1. Keine Ahnung was ich mir da gestern bei gedacht habe. Beste Grüße, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Reisezeiten (was: Potlach! *kotz*)
Hallo, on Saturday, 26 January 2008 10:39:05 +0100, Frederik Ramm [EMAIL PROTECTED] writes: Und es bleibt natürlich noch die Sache mit den Attributen, mit denen man auf eine Reisezeit schliessen kann. Da muss man faktisch bei Null anfangen, weil man das 'highway'- Attribut dafür nicht ernsthaft verwenden kann. Das ist Quatsch. Triff eine gute Abschaetzung anhand des highway-Attributes, und die Fehler in Deiner Berechnung werden garantiert geringer sein als die externen Einfluesse bei der tatsaechlichen Durchfuehrung der Fahrt (lies: Verkehr und Verkehrshindernisse). Jupp, auch die GDF-Daten der beiden Grossen lassen von der Functional Road Class nicht direkt auf Geschwindigkeiten bzw. Reisezeiten ableiten, da die FRC nur etwas die Wichtigkeit der Strasse im Gesamtnetz aussagt. Wo also kaum Autobahnen sind, wird auch eine eigentlich untergeordnete Strasse fuer eine Verbindung wichtig. Nur zusammen mit anderen Attributen (Form-of-Way, innerorts vs. ausserorts, Kurvigkeit, Anzahl Kreuzungen etc.) bekommt man gute Kanten-Reisezeiten. Wenn Du das auch nur ansatzweise mit einbeziehen wolltest, muesstest Du nicht nur speichern, wo Ampeln sind, sondern auch, wie viele Autos pro Ampelphase rueberkommen und wie viele Autos in Abhaengigkeit von der Tageszeit da stehen und so weiter. Das wird sicher irgendwann mal ein spannendes Projekt - aber *nachdem* wir ansonsten funktionierende Routingsysteme haben, nicht in Version 1.0. Ampeln etc. haben die beiden Grossen bislang auch (noch) nicht (flaechendeckend) drin, so dass alle Router/Navis die auch nicht einbeziehen koennen bzw. man mit alten Strassenkarten nicht verwendbare Ergebnisse bekommen muesste, wenn die denn so dringend notwendig waeren. Da die Navis auch schon vor Jahren (sehr) gute Ergebnisse lieferten ... :-) Viel wichtiger statt der Streit um die Brauchbarkeit der Highway-Tags ist IMHO das flaechendeckende Tagging, ob eine Strasse inner- oder ausserorts ist, egal ob dies ueber Ortsgrenzen, is_in-Builtup-Area- Tags oder per maxspeed=50/30/... passiert (ich versuche bspw. letzteres bei den von mir getaggten Strassen flaechendeckend zu tun). Wenn dann die Kantenzuege der Strasse einigermassen gut den Strassenverlauf, d.h. die Kurvigkeit und damit die tatsaechliche maximale Geschwindigkeit ableiten lassen, kann man eine brauchbare durchschnittliche Kanten-Geschwindigkeit aus all diesen ableiten, die fuer einen guten Durchschnitts-Router voellig ausreicht. Das groesste Problem aber ist leider immer noch, dass ich sehr haeufig nicht verbundene Way-Kreuzungen vorfinde, d.h. wo die Endknoten von zwei oder mehr Ways nicht verbunden sind, sondern nur knapp nebeneinander liegen. Und dies ist fuers Routing nun wirklich problematisch, da damit gerade die Routen im Nahbereich, also beim Start oder Ziel, oft unsinnige Ergebnisse liefern. Hier waere ein maplint- bzw. Josm-Validator-Test wirklich hilfreich, auch wenn ein solcher Test oefters false positives liefern wird, wo Wegenden sehr nahe beieinander liegen, aber eben doch (durch Mauern, Zaeune, unterschiedliche Hoehen) unueberwindbar getrennt sind. Das erinnert mich an die Schule, wo im Physikunterricht irgendeine komplett idealisierte Situation durchgerechnet wurde (punktfoermige Masse ohne Reibung...) und dann jemand stolz mit den vom Taschenrechner gelieferten 5 Stellen nach dem Komma ankommt. Jede praktische Anwendung wird 20% um den berechneten Wert herum schwanken, wozu also die Pseudopraezision? ... ganz zu schweigen von all den aufsummierten Rundungsfehlern, die man so bei einer ungluecklichen Implementierung machen kann :-). Die von einem Router berechnete Gesamtreisezeit wird ueblicherweise nur einige Prozent von der real benoetigten Reisezeit abweichen, solange man keine Staus und andere Stoerungen hat. Will man bessere Werte, d.h eine geringere Abweichung muss man so oder so dynamische Reisezeiten verwenden, d.h. zumindest tageszeitabhaengige Ganglinien, um so die ueblichen Pendlerstroeme mit einzubeziehen ... so wie dies auch (alle? die meisten?) aktuellen Router/Navis machen. Schoenes (Rest-)Wochenende, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] grade5 tracks nicht mehr in z16 ansicht?
Moin, du bist nicht allein, siehe Statistik zu tracktype http://etricceline.de/osm/germany/de_stats_tracktype.htm wenn osmarender über einen Tracktype stolpert, den er nicht kennt, wird der Track scheinbar einfach komplett weiß gemalt. Ich fände es besser, wenn er dann so täte, als wäre gar kein Tracktype gesetzt und den Track wie bisher malte. Schönen Sonntag, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] highway= vs. reale Eigenschaften
Am Sonntag, 27. Januar 2008 01:28:46 schrieb Gerald.Oppen: Man könnte es ihnen mit JOSM leicht machen: Eingabe des Tracks, Konvertierung in einen Way und Attributierung nach der administrativen Zuordnung die fast überall auf kleinen Schildchen am Strassenrand zu finden ist. Wird kein Highway-Attribut eingetragen so wird dies aufgrund der administrativen Bezeichnung zugeordnet. In der Regel wird man dami maximal 1-2 Stufen daneben liegen - nicht mehr als momentan durch die manuelle Zuordnung aufgrund unterschiedlicher Meinungen. Damit ist die Strasse schon mal in OSM vorhanden und verwendbar. Korrigieren kann sie dann immer noch jemand, die Hauptarbeit ist getan. Garry Man könnte auch noch weiter gehen und primary, secondary und tertiary absichtlich nach der Zuständigkeit vergeben und die Information zur Verkehrswichtigkeit der Straße einfach aus den real existierenden Attributen errechnen: maxspeed=, lanes=, ein tag für mittelstreifen, leitplanken usw... Ampeln gibts ja auch, also sehe Ich keinen Grund, warum ein Mapper sich die Arbeit machen soll, aus dem Bauch heraus (eventuell falsch) zu entscheiden, ob Straße A jetzt wichtiger/schneller/durchsatzstärker ist als Straße B oder umgekehrt. Dann kann der Router mit einer sehr feinen Bewertung arbeiten, um unterschiedliche Bedürfnisse zu erfüllen (Bauer Hannes will für seinen Rübentraktor eine Strecke zur Zuckerfabrik, die möglichst viel Feldweg enthält und wenn es doch eine Bundes/Landes/Kreisstraße sein muß, dann eine mit 2 oder mehr Spuren, damit er nicht 200 genervte Autofahrer hinter sich hat. Geschwindigkeit/Durchsatz ist ihm egal.). Der schöne-Bildchen-Renderer kann ebenfalls diese Daten heranziehen, um in seiner Darstellung darauf hinzuweisen, wie schnell oder durchsatzstark eine Straße ist. WENN ER DAS WILL. (andere wollen andere Dinge darstellen, z.B. aus Fahrradfahrer- oder Rübentraktorfahrersicht) Dann wird halt z.B. die Farbe vom highway-Attribut genommen und die Zeichnungsbreite von der Anzahl der Spuren, maxspeed usw. Mal ehrlich - was die Renderer im Moment machen ist doch pillepalle, sie setzen stur das highway-Attribut in eine starre Darstellung um. Im Prinzip ist das, was Ich vorschlage, für tracks gerade schon umgesetzt worden: dort beinflussen jetzt andere Werte (track_grade) die Darstellung mit, so daß der Renderer ein detailierteres Bild zeichnet. Klasse! Meines Erachtens müssen wir letztlich von der starren Anbetung des Highway-Attributes weg - es kann nur die gröbste Information liefern und eignet sich nicht dazu, eine Aussage über die Wichtigkeit zu treffen. Diese muß das Programm, das die Daten nutzt, auf Grundlage eines Regelwerkes treffen, das die jeweiligen Bedürfnisse des Benutzers berücksichtigt. (Auto, Fahrrad, Hundeschlitten... ;-) ) Und wenn Ich mir das Wachstum der Karte so ansehe, dann bin ich mir sicher, daß es bald eine Menge Mapper geben wird, die sich auf solche Details wie maxspeed, surface, trackgrade, lanes etc. stürzen werden, weil es kaum Wege gibt, die noch neu aufgemessen werden müssen. Dann werden vielleicht endlich auch mal einspurige Einbahnstraßen (z.B. bei baulicher Trennung oder ein Rechtsabbieger, um eine Ampel zu umgehen) nicht genauso fett gerendert wie zwei- oder dreispurige Ebs. oder Straßen, die in beide Richtungen befahrbar sind. :-) So, das wars. Was haltet ihr davon? MfG, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)
Hallo, Jupp, auch die GDF-Daten der beiden Grossen lassen von der Functional Road Class nicht direkt auf Geschwindigkeiten bzw. Reisezeiten ableiten, da die FRC nur etwas die Wichtigkeit der Strasse im Gesamtnetz aussagt. Wo also kaum Autobahnen sind, wird auch eine eigentlich untergeordnete Strasse fuer eine Verbindung wichtig. Nur zusammen mit anderen Attributen (Form-of-Way, innerorts vs. ausserorts, Kurvigkeit, Anzahl Kreuzungen etc.) bekommt man gute Kanten-Reisezeiten. Stimmt und deshalb geht mein Vorschlag dahin, ein paar Attribute einzuführen, die im Gegensatz zu 'highway' einigermassen exakt definiert sind und sich mit diesen Punkten beschäftigen. Ich baue keinen Router auf der highway-Info auf, weil ich nicht weiss, was sich der Mapper bei seinem Eintrag gedacht hat. Die statische Reisezeit (ohne Staus, etc.) wird ganz wesentlich von drei Bedingungen beeinflusst: Ausbau, Vorfahrt und Restriktionen wie Geschwindigkeitsbeschränkungen. Kurvigkeit ist eine ganz spezielle Geschichte und geht ja direkt aus dem Verlauf hervor. Im derzeitigen Zustand der Karte findet der Router wichtige Verkehrsbeziehungen nicht, weil sie aus der administrativen Zuordnung nicht hervorgehen. Ein schönes Beispiel ist die Umgehung von Rosenheim (OBB). Die ist derzeit als secondary drin und war schon mal tertiary. Damit ist sie nicht mehr aus dem normalen Hauptstraßengewirr herausgehoben und der Router schickt die Leute auf dem kürzesten Weg durch die Stadt, also mitten durch den Rummel mit vielen Ampeln. Alles was ich will ist, dass der Mapper (und damit auch ich ;)) ein Werkzeug an die Hand bekommt um auf die Straße zu schauen und die in OSM beschreiben: Das ist eine etwas breitere Kreisstraße die in diesem Bereich kreuzungsfrei ausgebaut ist und sehr verkehrswichtig ist. Solange er sich entscheiden muss, ob der jetzt trunk, secondary oder tertiary ist und jeweils wichtige Detailinfo auf der Strecke bleibt, ist das Verfahren suboptimal. Im Fall der Umgehung von Rosenheim bedeutet die derzeitige Einordnung, dass alle Routen die Rosenheim queren nicht die sind, die ein Anwender erwartet, der auf schnellstem Weg weiter will. Kleine Ursache, grosse Wirkung. Konkreter Vorschlag: highway bleibt secondary frc beschreibt die Wichtigkeit und divider beschreibt die kreuzungsfreiheit. Die von einem Router berechnete Gesamtreisezeit wird ueblicherweise nur einige Prozent von der real benoetigten Reisezeit abweichen, solange man keine Staus und andere Stoerungen hat. Will man bessere Werte, d.h eine geringere Abweichung muss man so oder so dynamische Reisezeiten verwenden, d.h. zumindest tageszeitabhaengige Ganglinien, um so die ueblichen Pendlerstroeme mit einzubeziehen ... so wie dies auch (alle? die meisten?) aktuellen Router/Navis machen. Na ja, über die Qualität des dynamischen Routings kann man sich streiten. Da ist wohl auch bei den grossen mehr Schein als Sein. Statistische Verfahren funktionieren so la la und die direkte Ableitung aus den Verkehrsmessgrößen (Induktionsschleifen/'Ufos') ist auch nicht viel besser. Grüsse Hubert -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Schweiz: Chaos am Gotthard und Oberalppass
Mehr zufällig bin ich auf ein ordentliches Chaos beim Gotthard und Oberalppass gestossen: http://www.openstreetmap.org/index.html?mlat=46.62mlon=8.564zoom=12 Die Gotthardstrasse und die angrenzenden Strassen sind teilweise 4x vorhanden und zusätzlich sind die Wege doppelt (mehrere Wege nutzen die gleichen Nodes). Zudem sind einige Nodes mit highway-Tags ausgestattet. Einige Strassen sind offensichtlich durch Umwandlung von GPS-Tracks entstanden, so dass viel zu viele Nodes verwendet wurden die sich teilweise auch noch selbst überlappen (Punktwolken von stehendem Fahrzeug). Ich habe angefangen dort aufzuräumen, aber mangels Ortskenntnis ist das schwierig. Kennt sich jemand dort aus? Insbesondere ist es schwierig herauszufinden, wo die Strassen richtungsgetrennt verlaufen, da die oneway Tags fehlen, aber andererseits die Wege und die GPS-Tracks danach aussehen. Gruss, Andy signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Potlach! *kotz*
Hallo, Das ist Quatsch. Also so hart würde ich das jetzt nicht sagen ;) Triff eine gute Abschaetzung anhand des highway-Attributes, und die Fehler in Deiner Berechnung werden garantiert geringer sein als die externen Einfluesse bei der tatsaechlichen Durchfuehrung der Fahrt (lies: Verkehr und Verkehrshindernisse). B baut auf Informationen auf, die A liefert. Wenn die Beschreibung der Straße schon nicht stimmt, kann man deutlich schlechter abschätzen, was dynamisch passieren kann. Ein Stau auf einer kreuzungsfrei ausgebauten Straße ist anderer Natur als einer auf einer Ampelstrecke. Aber Stau als Grund vorzuschieben, dass eine Reisezeitabschätzung ja gar nicht möglich ist, ist problematisch. Bin nicht mehr so ganz gut informiert, aber die chaotische Natur des Staus hat sich eigentlich ganz gut etabliert. Damit ist ein Stau so gut wie nicht vorhersehbar, aber sehr wohl die Reisezeit ohne Stau. Aber soll man auf die Schätzung der statischen Reisezeit deshalb verzichten? Wenn Du das auch nur ansatzweise mit einbeziehen wolltest, muesstest Du nicht nur speichern, wo Ampeln sind, sondern auch, wie viele Autos pro Ampelphase rueberkommen und wie viele Autos in Abhaengigkeit von der Tageszeit da stehen und so weiter. Das wird sicher irgendwann mal ein spannendes Projekt - aber *nachdem* wir ansonsten funktionierende Routingsysteme haben, nicht in Version 1.0. Das ist jetzt alles nicht unbedingt neu und in vielen Forschungsarbeiten kann man nachlesen, welche Parameter braucht um da eine Abschätzung zu treffen. Man braucht also nicht unbedingt zu warten. Egal wie mans angeht, umso genauer man am Anfang arbeitet, desto besser kommt man später vom Fleck. Das erinnert mich an die Schule, wo im Physikunterricht irgendeine komplett idealisierte Situation durchgerechnet wurde (punktfoermige Masse ohne Reibung...) und dann jemand stolz mit den vom Taschenrechner gelieferten 5 Stellen nach dem Komma ankommt. Jede praktische Anwendung wird 20% um den berechneten Wert herum schwanken, wozu also die Pseudopraezision? Keine Pseudopräzision - nur der Versuch, das sauber zu erfassen, was einfach zu erfassen ist um dass darauf aufzubauen. Eine einbahndurchzogene 30er-Zone soll effektiv von einer Ampelstrecke oder von einer gut funktionierenden Umgehung zu unterscheiden sein. Vorfahrt ist da z.B. ein zentrales Thema. Eine Klassifizierung, die auf den realen Vorfahrtsverlauf Rücksicht nimmt, ist fürs Routing effektiver als die Annahme dass die administrative Einteilung da pauschal zu stimmen hat. Grüsse Hubert -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)
Am Sonntag 27 Januar 2008 schrieb qbert biker: Hallo, Jupp, auch die GDF-Daten der beiden Grossen lassen von der Functional Road Class nicht direkt auf Geschwindigkeiten bzw. Reisezeiten ableiten, da die FRC nur etwas die Wichtigkeit der Strasse im Gesamtnetz aussagt. Wo also kaum Autobahnen sind, wird auch eine eigentlich untergeordnete Strasse fuer eine Verbindung wichtig. Nur zusammen mit anderen Attributen (Form-of-Way, innerorts vs. ausserorts, Kurvigkeit, Anzahl Kreuzungen etc.) bekommt man gute Kanten-Reisezeiten. Stimmt und deshalb geht mein Vorschlag dahin, ein paar Attribute einzuführen, die im Gegensatz zu 'highway' einigermassen exakt definiert sind und sich mit diesen Punkten beschäftigen. der sinn und das schoene am highway-tag ist ja eigentlich, mit einem tag eine strasse kategorisieren zu koennen. dass das immer irgendwie schwammig bleiben wird, sist eigentlich klar. auch ein neues definiertes tagging-schema wuerde da warscheinlich bei vielen strassen an seine grenzen stossen, wenn auch die zuordnung wohl genauer werden wuerde. inzwischen werden ja immer wieder irgendwelche zusatztags und attribute verwendet, um die gegebenheiten besser abzubilden. vielleicht waere es da nicht mal so verkehrt, generell etwas von dem ein tag beschreibt alles schema etwas wegzukommen. d.h. es gibt nicht mehr ein highway-tag, sondern ein paket von drei oder vier genau definierten attributen, die die strasse beschreiben, und dies wesentlich genauer koennen. Im Fall der Umgehung von Rosenheim bedeutet die derzeitige Einordnung, dass alle Routen die Rosenheim queren nicht die sind, die ein Anwender erwartet, der auf schnellstem Weg weiter will. Kleine Ursache, grosse Wirkung. Konkreter Vorschlag: highway bleibt secondary frc beschreibt die Wichtigkeit und divider beschreibt die kreuzungsfreiheit. sowas in der richtung... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Dupe-Nodes
On Sat, Jan 26, 2008 at 02:36:58AM +0100, Andreas Stricker wrote: [Dupe-Nodes] D.h. diese Nodes sind auch nicht Way zugeordnet mit unterschiedlichen layer oder ele-Tags? Gut, daß Du mich daran erinnerst. Es gibt tatsächlich drei Kandidatenpärchen mit unterschiedlichen Layern. Die sollten natürlich nicht zusammengefasst werden, Sonst sehe ich hier kein Problem. Aber um ganz sicher zu gehen: Könntest du die Änderungen zum Peer-Review online stellen? Klar. Die Vorauswahl ist ja bereits online... [1] http://sascha.silbe.org/osm/dupeNodeInfo.lst Geht im Moment bei mir leider nicht (connection refused). ... und auch wieder erreichbar. Du hast leider ausgerechnet die (halbe?) Stunde erwischt, wo der Webserver nach Update fehlerhaft konfiguriert war (benutze einen Server mit, auf dem leider ein Apache läuft). Habe die Datei jetzt um Informationen zu den betroffenen Wegen ergänzt. Nur eine einzige Relation (#2708) enthält Nodes, zu denen Duplikate existieren. Diese Nodes haben jedoch Attribute (highway=minor), so daß sie sowieso nicht angerührt werden. Dateiformat ist (pro Zeile): nodeId lat lon nodeTags wayTags Wobei nodeTags und wayTags jeweils Dictionaries sind mit nodeId bzw. wayId als Key und den Tags als Value. Nicht toll zu lesen, aber für eine kurze Übersicht ausreichend. Enthalten sind alle Dupe-Nodes, nicht nur die Merge-Kandidaten. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ pgpymPfyZaAla.pgp Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Dupe-Nodes
Sascha Silbe [EMAIL PROTECTED] writes: Nachdem ich jetzt endlich meine Datenbank auf die v5-Ways umgestellt habe, bin ich mal wieder auf die Node-Dubletten aufmerksam geworden. Eine schnelle Analyse hat gezeigt, daß der überwiegende Anteil (im Deutschland-Extrakt) außer created_by und converted_by keine Tags hat und somit sehr einfach zusammengefasst werden könnte. Es gab eine ganz spezifische Potlatch-Version (0.4d IIRC), die Dubletten produziert hat, obwohl keine haetten entstehen sollten. Diese koennte man wohl ziemlich gefahrlos zusammenfassen. Bei den anderen ist es u.U. etwas schwieriger. Cheers Colin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Probleme mit Potlach undqy
Hallo, hättet ihr nicht langsam mal Lust, die Betreffzeile zu ändern? Wieso, ist doch schoen ;-) Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Probleme mit Potlach undqy
Hallo, On Mon, Jan 28, 2008 at 04:18:59AM +0100, Frederik Ramm wrote: Wieso, ist doch schoen ;-) Aeh, sorry, die Mail hatte ich eigentlich verworfen, und irgendwie ist sie doch noch durchgerutscht, daher auch das kaputte subject. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Reisezeiten
Im derzeitigen Zustand der Karte findet der Router wichtige Verkehrsbeziehungen nicht, weil sie aus der administrativen Zuordnung nicht hervorgehen. Ein schönes Beispiel ist die Umgehung von Rosenheim (OBB). Die ist derzeit als secondary drin und war schon mal tertiary. Was ich immer sage: die administrativen Zuordnung wird überbewertet. An Deiner Stelle würde ich die Umgehung eine Stufe höher und die Bundesstraße eine Stufe niedriger zu taggen. Und zwar jetzt sofort. Paul ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Schweiz: Chaos am Gotthard und Oberalppass
Hi, Ich habe angefangen dort aufzuräumen, aber mangels Ortskenntnis ist das schwierig. Kennt sich jemand dort aus? Ich schau heut abend mal rein, sollte auch noch ein paar klärende Urlaubstracks von dort haben. Die sind aber meist mit der via Tremola... -- Ciao, Holger (GUS-KOTAL, GUS#1100) 90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm 95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 69 Mm (Die Renndrecksau!) cu @ http://www.issle.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [OSM-talk-fr] vélib
Axel Rousseau a écrit : Axel Marquette a écrit : Axel Rousseau wrote: As-tu regénéré la tile ? Je vais lancer un render sur TAH, ca sera prêt d'ici une heure. tu fais comment pour regénérer un render ? Axel http://wiki.openstreetmap.org/index.php/Tiles%40home TilesAtHome est client qui te permet de télécharger les données d'OSM pour une zone de carte en zoom12, de faire tourner Osmarender et Maplint pour générer les tiles correspondantes, et d'uploader le tout sur le serveur pour consultation. C'est utile par exemple quand tu as fini d'éditer une zone et que tu veux voir le résultat. Sinon à côté de ça tu peux demander l'actualisation de tiles sur l'informationfreeway, et le serveur enverra ta demande à ceux qui font tourner TAH en boucle (plus long). Axel#2 oki, je crois que je vais laisser informationfreeway envoyer les tiles à calculer plutot que d'installer quelque chose sur ma machine. Merci pour les explications, Axel Oui, mais n'oublie pas dans ce cas de demander un rendu ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] comment délimiter un arrondissemen t à paris ?
la question était si la limite s'affichait sans être fermée... et la réponse était oui. Maintenant pour en faire d'avantage comme différentes pistes qui me sont venues à l'esprit, effectivement, l'idéal est de fermer la boucle. 2008/1/27 Axel Rousseau [EMAIL PROTECTED]: Par contre, une limite administrative comme un arrondissement ou un département pourrait servir à faire des cartes concentrées sur ces zones, ou à faire une extraction de base de donnée, ou à créer des statistiques par zone (liste de tags, quantité de points velib, points de recyclage, kilometres de pistes cyclables) dans une page html... enfin bref, tous les usages possible d'une cartographie ayant besoin d'une limite administrative. C'est sans limite. je vois pas trop comment on peut savoir si un node se trouve à l'intérieur ou à l'extérieur d'une limite si celle ci n'est pas fermée... Mes souvenirs de licence d'informatique me disent que c'était quasi-impossible à savoir. Axel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] comment délimiter un arrondissemen t à paris ?
en fait, je me posais la question sur ce que tu disais en terme d'extraction, de statistiques... Comment extraire des infos pour des stats avec uniquement les limites administratives ? Autre question : quels sont les autres types de limites qu'il faut utiliser pour délimiter une ville ? (Je pense qu'il faut faire un place=city sur un area, est ce que ça ne fait pas double emploi avec le boundary=administrative ?) Dernière question : y'a t'il un moyen de faire l'intersection des maps et d'une area ? En fait, je voudrais récuperer toutes les ways/node de issy et uniquement eux, c'est à dire que je ne veux pas la seine en dehors d'issy (si je fais un import, il m'affiche les ways qui sont dans la zone, mais avec les ways en entier (et comme certains ways sont très longs, ça fait bcp de déchets...) Merci, Axel la question était si la limite s'affichait sans être fermée... et la réponse était oui. Maintenant pour en faire d'avantage comme différentes pistes qui me sont venues à l'esprit, effectivement, l'idéal est de fermer la boucle. 2008/1/27 Axel Rousseau [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Par contre, une limite administrative comme un arrondissement ou un département pourrait servir à faire des cartes concentrées sur ces zones, ou à faire une extraction de base de donnée, ou à créer des statistiques par zone (liste de tags, quantité de points velib, points de recyclage, kilometres de pistes cyclables) dans une page html... enfin bref, tous les usages possible d'une cartographie ayant besoin d'une limite administrative. C'est sans limite. je vois pas trop comment on peut savoir si un node se trouve à l'intérieur ou à l'extérieur d'une limite si celle ci n'est pas fermée... Mes souvenirs de licence d'informatique me disent que c'était quasi-impossible à savoir. Axel ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
