[Talk-hr] Sretna nova
Sretna Vam nova 2012. godina! Bilo bi dobro sastaviti neku listu prioriteta za 2012 godinu. ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
[OSM-talk-be] New Year's meeting in STUK Leuven on January 6th
I turned the informal meeting into a New Year's meeting, so now everybody has to come, of course :-) ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] Request for Romano-British features
On 2 January 2012 09:49, Michael Collinson m...@ayeltd.biz wrote: ** I've been using historic=roman_road but will be switching to historic=road, culture=roman as per an excellent tagging schema proposed by Francesco de Virgilio at http://wiki.openstreetmap.org/wiki/User:Fradeve11/prove2 , as this will enable a pan-European approach. I hadn't seen that proposal - I agree it would be good to have a world-wide scheme, but I am concerned that we could potentially end up with different tagging schemes here...and I know how unpopular it would be to 'correct' them electronically in the future As far as I can tell there is: 1. The proposed culture= (no wiki page for it yet other than http://wiki.openstreetmap.org/wiki/User:Fradeve11/prove2 2. historic:civilization= - https://wiki.openstreetmap.org/wiki/Key:historic:civilization I started a wiki page to record how British historical sites are tagged ( https://wiki.openstreetmap.org/wiki/WikiProject_Historic_Britain) - It would be good to update that with the proposal - the main thing that is missing from it is a list of 'cultures' or 'civilizations' that we can all use. Neither culture nor historic:civilization are that well used, but there are more historic:civilization entries (see http://taginfo.osm.org). What I intend to do with my map is to have different layers for different cultures/civilizations so that you can see all roman features, or all cold war relics etc. Regards Graham. -- Graham Jones Hartlepool, UK. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Request for Romano-British features
the main thing that is missing from it is a list of 'cultures' or 'civilizations' that we can all use. In the UK at least there's a defined and well used list of periods provided by the Archaeology Data Service: http://archaeologydataservice.ac.uk/Imagebank/period.jsf In short, is something like: Palaeolithic 500 000 - 10 000 BC Mesolithic 10,000 - 4,000 BC Neolithic 4000 - 2200 BC Bronze Age 2500 - 700 BC Iron Age 800 BC - 43 AD Roman 43 - 410 AD Early Medieval 410 - 1066 AD Medieval 1066 - 1540 AD Post Medieval 1540 - 1901 AD Modern 1901 - present For the data to be useful for a wider community than OSM, I would strongly suggest following these dates and terms. It's what i use on my grey literature site, for example: http://library.thehumanjourney.net/view/subjects/UK-periods.html Please be aware that 'cultures' or 'civilizations' don't really work in British archaeology (or anywhere in Europe) any more - we've given up on Culture Historical interpretations of the past. I guess it's only really a matter of semantics, but dealing with periods rather than civilisations will make it much easier to draw in data from the outside world. Also please note that the above list is for the UK only. On the continent, for example, different things happened and happened at different times. It probably wouldn't be possible to get a coherent tagging scheme across Europe that made any sense; there's simply not a consistent European past that could be represented in such a way. Cheers, Joseph On 2 January 2012 11:12, Graham Jones grahamjones...@gmail.com wrote: On 2 January 2012 09:49, Michael Collinson m...@ayeltd.biz wrote: I've been using historic=roman_road but will be switching to historic=road, culture=roman as per an excellent tagging schema proposed by Francesco de Virgilio at http://wiki.openstreetmap.org/wiki/User:Fradeve11/prove2 , as this will enable a pan-European approach. I hadn't seen that proposal - I agree it would be good to have a world-wide scheme, but I am concerned that we could potentially end up with different tagging schemes here...and I know how unpopular it would be to 'correct' them electronically in the future As far as I can tell there is: The proposed culture= (no wiki page for it yet other than http://wiki.openstreetmap.org/wiki/User:Fradeve11/prove2 historic:civilization= - https://wiki.openstreetmap.org/wiki/Key:historic:civilization I started a wiki page to record how British historical sites are tagged (https://wiki.openstreetmap.org/wiki/WikiProject_Historic_Britain) - It would be good to update that with the proposal - the main thing that is missing from it is a list of 'cultures' or 'civilizations' that we can all use. Neither culture nor historic:civilization are that well used, but there are more historic:civilization entries (see http://taginfo.osm.org). What I intend to do with my map is to have different layers for different cultures/civilizations so that you can see all roman features, or all cold war relics etc. Regards Graham. -- Graham Jones Hartlepool, UK. ___ 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] Wrong weblink/page on wiki home page: Gemeinschafts-Portal (DE:Mapping_projects?)
Hi Erik Thanks for the hint. I also thought about that. But I am very reluctant to use redirects to compensate mistakes. In this case it's obvious that the original URL (and name!) should be corrected. Is anybody here who is able to change the navigation link? Yours, Stefan 2012/1/1 Erik Johansson e...@kth.se: On Sun, Jan 1, 2012 at 12:55, Stefan Keller sfkel...@gmail.com wrote: Who is caring for the german translation of the current OSM wiki? In the german GUI translation of the wiki homepage (Mediawiki) there seems to be a void weblink: In the navigation panel, the weblink Gemeinschafts-Portal points to [[OpenStreetMap:Gemeinschafts-Portal]] which is an empty page. I think this should point to [[DE:Mapping_projects]]. If this is the intended target URL then I pose the question if the Gemeinschafts-Portal should'nt be translated as Gemeinschaftsprojekte? In Swedish it links to: OpenStreetMap:Deltagarportalen which is also blank. But you can add a redirect, e.g. #redirect[[DE:Mapping_projects]] on OpenStreetMap:Gemeinschafts-Portal and you should get what you want. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wrong weblink/page on wiki home page: Gemeinschafts-Portal (DE:Mapping_projects?)
On 02/01/12 12:32, Stefan Keller wrote: Thanks for the hint. I also thought about that. But I am very reluctant to use redirects to compensate mistakes. In this case it's obvious that the original URL (and name!) should be corrected. Is anybody here who is able to change the navigation link? It's a wiki - anybody can change it. At least I don't think that page is protected at all. I think this is the one you want: http://wiki.openstreetmap.org/wiki/MediaWiki:Portal-url/de Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] map for GPS and local
hi all based on my experience last year (happy new year all), we install the indonesian map to our mapnik in osmosa.net, and we get the ZEE get problem, and after we put global map, 2 week work in our server.. all goes well since then. i have an idea to produce indonesia map only, with better than our last experience. our team will replicate the global data , and put indonesia only, i see geofabric do smiliar thing . can share a best tips to extract global data to local data. sorry if this question is a repeated. F ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Request for Romano-British features
On Thu, 22 Dec 2011 13:02:59 + Joseph Reeves iknowjos...@gmail.com wrote: I must have had a blond moment when I tried searching for start_date as I got no results there. https://wiki.openstreetmap.org/wiki/Key:start_date The idea would be to include start_date and end_date keys to enable a temporal GIS approach to the data. An online map could include a time slider, for example, that would respect these keys and show the requested features. It was a major 'blonde moment', I just realised you were saying to ADD start end date tags, rather than search for them in the existing data mick ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Request for Romano-British features
On 2 January 2012 11:58, Joseph Reeves iknowjos...@gmail.com wrote: the main thing that is missing from it is a list of 'cultures' or 'civilizations' that we can all use. In the UK at least there's a defined and well used list of periods provided by the Archaeology Data Service: http://archaeologydataservice.ac.uk/Imagebank/period.jsf That list has an elegant simplicity about it. Richard Light added a link to the wiki page to a classification system used by English Heritage ( http://light.demon.co.uk/eh-periods.rdf). Unfortunately it is in quite a complicated format, and I have not had chance to sit down and decode it into a simple proposal for tagging - do you know how this compares to your list? Also please note that the above list is for the UK only. On the continent, for example, different things happened and happened at different times. It probably wouldn't be possible to get a coherent tagging scheme across Europe that made any sense; there's simply not a consistent European past that could be represented in such a way. I agree - the historic:civilizationhttp://wiki.openstreetmap.org/wiki/Key:historic:civilizationpage has recommendations for different regions, so we would just need to add a suitable UK (or British Isles?), scheme to it. My concern was more about using 'culture' rather than 'civilization' and 'period' as that would seem to be a competing tagging system, rather than just a regional variation on a general scheme. Regards Graham. -- Graham Jones Hartlepool, UK. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Request for Romano-British features
Graham Jones wrote: I agree - the historic:civilization http://wiki.openstreetmap.org/wiki/Key:historic:civilization page has recommendations for different regions, so we would just need to add a suitable UK (or British Isles?), scheme to it. My concern was more about using 'culture' rather than 'civilization' and 'period' as that would seem to be a competing tagging system, rather than just a regional variation on a general scheme. Historic mapping wiki page has yet to be created, but start_date and end_date would seem to replace the need for Key:historic:period if accurate data is available. Having been watching a program recently on the development of various industrial areas of the UK, it would seem that there is substantial data available to provide historic maps. Development and decline of the railway system for example is something I've been gathering historic maps that provides considerable accurate timelines. The only question that still has not been addressed is one that covers a lot of parallel data. SHOULD it be uploaded to the main database, or should we have a working method for linking secondary databases into the rendering process. Which to my mind still provides the most logical way forward. But at what point does an historic element get degraded to the secondary storage area? Or more important ... what classifies historic data as being 'main stream'? -- 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] Request for Romano-British features
On 2 January 2012 15:47, Lester Caine les...@lsces.co.uk wrote: Historic mapping wiki page has yet to be created, but start_date and end_date would seem to replace the need for Key:historic:period if accurate data is available. I think the issue is availability of accurate data - I am pretty confident that I can look at a building and think it is Tudor, or a fortress and guess that it is Nepoleonic, but guessing the date seem somehow harder to me. I would like the tagging to be accessible to non-history buffs, so more qualitative categories would seem easier than trying to be too precise. By all means include start_date if it is known though! Having been watching a program recently on the development of various industrial areas of the UK, it would seem that there is substantial data available to provide historic maps. Development and decline of the railway system for example is something I've been gathering historic maps that provides considerable accurate timelines. I like this sort of thing too, which is why we will need more categories than currently proposed 'modern' is too wide given all the changes in the 20th Century. The only question that still has not been addressed is one that covers a lot of parallel data. SHOULD it be uploaded to the main database, or should we have a working method for linking secondary databases into the rendering process. Which to my mind still provides the most logical way forward. But at what point does an historic element get degraded to the secondary storage area? Or more important ... what classifies historic data as being 'main stream'? My view is that if it is something that is still there on the ground (e.g. the ruins of an old tin mine), then it should go in the main database. If there is nothing physically to see, it belongs in a specialist historic map. I haven't thought about how to make this separate map though Regards Graham. -- Graham Jones Hartlepool, UK. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Request for Romano-British features
On Mon, 02 Jan 2012 15:47:15 + Lester Caine les...@lsces.co.uk wrote: The only question that still has not been addressed is one that covers a lot of parallel data. SHOULD it be uploaded to the main database, or should we have a working method for linking secondary databases into the rendering process. Which to my mind still provides the most logical way forward. But at what point does an historic element get degraded to the secondary storage area? Or more important ... what classifies historic data as being 'main stream'? Historic data is 'main stream' when it is still visible in the landscape and becomes secondary when it stops being visible, for example a Tudor Manor House that has been wholly swallowed by a later mansion would be a target for the secondary stream but its Coach House that was remodelled, leaving its Tudor Heritage visible in the facade would remain in the main stream. MY OPINION FROM A GLANCE AND A GUESS AT THE RULES mick ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] New version of the parking map
Hi all, Happy new year! I updated the parking map style on http://parking.openstreetmap.de Changes are: * new keywords are now accepted for parking:lane:* * parallel instead of inline * perpendicular instead of orthogonal * the old keywords are supported for a while, but discouraged * vending machines for parking tickets are now displayed * Parking lots for shops have now the shop names (parking:condition:area:customers=xxx) * Parking nodes are now displayed with the correct color (i.e. green for free, etc.) * Parking areas are now semi-transparent, so that the parking_aisles are seen through * incomplete data (i.e. unknown parking condition) is displayed in purple) Please debug your area (use /dirty to redraw tiles) and comment on any bugs/wishes. Also, try to add additional tags for purple parking lots (best: parking:condition:area= free/ticket/customers/private/disc, at least: fee=yes/no) Kind regards, Kay ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Roman road map of Britain
On Mon, 02 Jan 2012 18:22:25 +0100 Michael Collinson m...@ayeltd.biz wrote: Dear Keith, I found your Roman road maps http://keithbriggs.info/Roman_road_maps.html and greatly enjoyed looking at them. Thank you for making them available. I wonder if you would be willing to share the coordinate data used to map the roads? I am an OpenStreetMap contributor http://www.openstreetmap.org . I also have an interest in mapping UK roman roads and historic mining sites so that anyone can make specialist maps from the data. One resource the project has developed is the ability to trace directly from out-of-copyright Ordnance Survey maps. I am using this but it is a slow business and we cannot use anything published later than the 1950s (crown copyright is 50 years). You can see our progress here: http://maps3.org.uk/tiles/historic.html Roman roads are marked in blue. All the underlying data is publicly available from the project's database. I am also cc'ing Mick who has an independent interest in the same area. Regards, Mike Michael Collinson PS Just reading http://keithbriggs.info/Bayes_placenames-2.html . It is fascinating. I have my 'close approximation' digitisation of Keith Briggs full map of roads and places as separate MapInfo layers I could send you although I am a bit concerned about copyright, Briggs seems to have worked from a book by Margary that was published in 1957 so is still under copyright. If needed I know I could convert it to ESRI shape file, think I can convert to OSM XML file too but I'd need to research that one. I have been using Bill Thayer's Lacus Curtius site http://penelope.uchicago.edu/Thayer/E/Gazetteer/Places/Europe/Great_Britain/_Periods/Roman/home.html It seems to be down right now, it seems to do that every holiday weekend. let me know mick ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Request for Romano-British features
On Mon, Jan 2, 2012 at 6:45 PM, Lester Caine les...@lsces.co.uk wrote: What is difficult to separate is where an object IS still on the ground but now has a different designation. Or still there but not visible (e.g. underground). Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wrong weblink/page on wiki home page: Gemeinschafts-Portal (DE:Mapping_projects?)
Hi Tom 2012/1/2 Tom Hughes t...@compton.nu wrote: It's a wiki - anybody can change it. At least I don't think that page is protected at all. I think this is the one you want: http://wiki.openstreetmap.org/wiki/MediaWiki:Portal-url/de I'm pretty sure you need admin rights for this links (these pages are locked for users). And changing the sidebar/navigation you even need sys admin rights (see http://www.mediawiki.org/wiki/Manual:Interface/Sidebar ). So do you know somebody who can take action? Having looked once again at the sidebar/navigation, there are even more translation issues at least for the german interface languages de and de_ch. Currently sidebar/navigation loos like this (in de and de_ch as interface language): Hauptseite The map Gemeinschafts-Portal ... Donations But it should become something like this: Hauptseite Die Karte Mapping-Projekte ... Spenden Yours, Stefan 2012/1/2 Tom Hughes t...@compton.nu: On 02/01/12 12:32, Stefan Keller wrote: Thanks for the hint. I also thought about that. But I am very reluctant to use redirects to compensate mistakes. In this case it's obvious that the original URL (and name!) should be corrected. Is anybody here who is able to change the navigation link? It's a wiki - anybody can change it. At least I don't think that page is protected at all. I think this is the one you want: http://wiki.openstreetmap.org/wiki/MediaWiki:Portal-url/de Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wrong weblink/page on wiki home page: Gemeinschafts-Portal (DE:Mapping_projects?)
On 02/01/12 19:43, Stefan Keller wrote: I'm pretty sure you need admin rights for this links (these pages are locked for users). Ah ok. It wasn't listed protected but the Mediawiki pages may be protected implicitly or something. So do you know somebody who can take action? Having looked once again at the sidebar/navigation, there are even more translation issues at least for the german interface languages de and de_ch. I do have admin right but I'm no expert on mediawiki so probably best to wait for Grant to show up as he will know more about it than me. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Request for Romano-British features
Graham Jones grahamjones...@gmail.com wrote: On 2 January 2012 15:47, Lester Caine les...@lsces.co.uk wrote: Historic mapping wiki page has yet to be created, but start_date and end_date would seem to replace the need for Key:historic:period if accurate data is available. I think the issue is availability of accurate data - I am pretty confident that I can look at a building and think it is Tudor, or a fortress and guess that it is Nepoleonic, but guessing the date seem somehow harder to me. I would like the tagging to be accessible to non-history buffs, so more qualitative categories would seem easier than trying to be too precise. By all means include start_date if it is known though! Having been watching a program recently on the development of various industrial areas of the UK, it would seem that there is substantial data available to provide historic maps. Development and decline of the railway system for example is something I've been gathering historic maps that provides considerable accurate timelines. I like this sort of thing too, which is why we will need more categories than currently proposed 'modern' is too wide given all the changes in the 20th Century. The only question that still has not been addressed is one that covers a lot of parallel data. SHOULD it be uploaded to the main database, or should we have a working method for linking secondary databases into the rendering process. Which to my mind still provides the most logical way forward. But at what point does an historic element get degraded to the secondary storage area? Or more important ... what classifies historic data as being 'main stream'? My view is that if it is something that is still there on the ground (e.g. the ruins of an old tin mine), then it should go in the main database. If there is nothing physically to see, it belongs in a specialist historic map. I haven't thought about how to make this separate map though As far as rendering is concerned, it would be useful to be able to set starting and ending dates for a given renderiing, so that eventually you compare a series of maps and see patterns of changes. In some cases, you might want to show only the time period of interest; in other cases, you might want to show both historic data and current-day data. -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] osmosis pbf issues
I have been trying to process pbf files without luck in osmosis. When i run: osmosis --read-pbf india.osm.pbf --write-xml india.osm osmosis quits with: SEVERE: Execution aborted. org.openstreetmap.osmosis.core.OsmosisRuntimeException: Task type read-pbf doesn't exist. I installed osmosis 0.39 using 'apt-get intall osmosis' I used to get the same error when i used osmosis from http://bretth.dev.openstreetmap.org/osmosis-build/osmosis-latest.zip a month ago How do i get pbf to work? i dont see any help in the wiki either. cheers -- j.mp/ArunGanesh http://j.mp/ArunGanesh ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Request for Romano-British features
John F. Eldredge wrote: As far as rendering is concerned, it would be useful to be able to set starting and ending dates for a given renderiing, so that eventually you compare a series of maps and see patterns of changes. In some cases, you might want to show only the time period of interest; in other cases, you might want to show both historic data and current-day data. This is the area that we still need to get some agreement on :( Current rendering does not take any notice of start and stop dates ... -- 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-nl] Het IJ leeggepompt!
Als je ook nog zin hebt om naar deze te kijken kan de scheepvaart worden hervat: http://www.openstreetmap.org/?lat=52.4098lon=4.8123zoom=14layers=M Gr, Floris 2011/12/30 Frank Steggink stegg...@steggink.org: Ik hoop het nu opgelost te hebben: http://www.openstreetmap.org/browse/changesets?bbox=4.90268%2C52.36723%2C4.97632%2C52.39065 Wat er precies aan de hand was: geen idee. Eerst dacht ik dat het komt omdat er twee multipolygonen waren, dus ik heb er een (rel. nr. 1704: komt nog uit de AND-import) verwijderd. Dat hielp niet. Later heb ik de 3 polygonen met de naam Het IJ gemerged, aangezien er verder geen verschil hiertussen zit.. Dat was nog niet voldoende, dus heb ik wat edits in de omgeving gemaakt. Uiteindelijk kon het oostelijke deel van de IJhaven pas gerenderd worden nadat ik twee eilandjes had toegevoegd die ik op Bing zag. Groeten, Frank On 30-12-2011 13:14, Floris Looijesteijn wrote: Het is weer flink mis... http://www.openstreetmap.org/?lat=52.37667lon=4.93481zoom=15layers=M gr, floris 2011/12/27 Willem Sonkewillemso...@planet.nl: Het commentaar bij deze changeset is /MP repairs (OSMI)/. De OSM Inspector [1] geeft in deze regio inderdaad multipolygoonfouten, onder meer /touching inner rings/ en /invalid geometry/. Deze gebruiker heeft overigens ook op andere plaatsen dergelijke veranderingen gedaan, waaronder in Den Haag, maar daar zie ik zo snel geen problemen op de kaart. Willem Sonke [1] http://tools.geofabrik.de/osmi/?view=multipolygonlon=4.83140lat=52.41107zoom=13overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes On 27-12-11 15:30, Piet Smits wrote: Iemand heeft op 22 december deze way uit de relatie 1704 (die het zelfde lijkt als relatie Het IJ) gehaald. Wellicht had het daar iets mee te maken: http://www.openstreetmap.org/browse/relation/1704/history Bij de monding van de Ertshaven zie (of zag) je hetzelfde. grtz, Piet Op 27-12-2011 15:15, Floris Looijesteijn schreef: http://www.openstreetmap.org/browse/way/67559262 Ja, Willem1, die wijziging is te zien. Op dit moment wordt ie ook weer goed gerenderd. Renderbugje dus denk ik... Thanks all! Groet, Floris 2011/12/27 Floris Looijesteijno...@floris.nu: Volgens mij is die historie niet actueel. De weg waar ik het in m'n andere mailtje over heb, heb ik net enorm aan lopen trekken maar die staat nog steeds op de vorige editor z'n naam. Groet, Floris 2011/12/27 Maarten Deenmd...@xs4all.nl: On 2011-12-27 14:03, Floris Looijesteijn wrote: http://www.openstreetmap.org/?lat=52.37914lon=4.92726zoom=15layers=M Wie heeft er zin om even te kijken wat er aan de hand is? Vreemd. Dat stukje IJ is sinds juli 2010 niet aangeraakt: http://www.openstreetmap.org/browse/way/67559262 3dshapes:ggmodelk = 23 name = Het IJ natural = water source = 3dShapes Lijkt ok. Ik kan in Potlatch alleen niet controleren of de way helemaal correct is (closed en continuous). Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Het IJ leeggepompt!
Ook hier zie ik geen fout in JOSM. Bij het opnieuw renderen van het gebied wordt de Westhaven nu wel goed gerenderd, behalve het stukje bij ADM. Misschien kan hier Lennard of iemand anders even naar kijken, aangezien hij het renderingproces beter begrijpt. Er zit blijkbaar iets fout. Misschien een Mapnik-update? Ik pas nu niks aan aan de data. Frank On 2-1-2012 9:50, Floris Looijesteijn wrote: Als je ook nog zin hebt om naar deze te kijken kan de scheepvaart worden hervat: http://www.openstreetmap.org/?lat=52.4098lon=4.8123zoom=14layers=M Gr, Floris 2011/12/30 Frank Stegginkstegg...@steggink.org: Ik hoop het nu opgelost te hebben: http://www.openstreetmap.org/browse/changesets?bbox=4.90268%2C52.36723%2C4.97632%2C52.39065 Wat er precies aan de hand was: geen idee. Eerst dacht ik dat het komt omdat er twee multipolygonen waren, dus ik heb er een (rel. nr. 1704: komt nog uit de AND-import) verwijderd. Dat hielp niet. Later heb ik de 3 polygonen met de naam Het IJ gemerged, aangezien er verder geen verschil hiertussen zit.. Dat was nog niet voldoende, dus heb ik wat edits in de omgeving gemaakt. Uiteindelijk kon het oostelijke deel van de IJhaven pas gerenderd worden nadat ik twee eilandjes had toegevoegd die ik op Bing zag. Groeten, Frank On 30-12-2011 13:14, Floris Looijesteijn wrote: Het is weer flink mis... http://www.openstreetmap.org/?lat=52.37667lon=4.93481zoom=15layers=M gr, floris 2011/12/27 Willem Sonkewillemso...@planet.nl: Het commentaar bij deze changeset is /MP repairs (OSMI)/. De OSM Inspector [1] geeft in deze regio inderdaad multipolygoonfouten, onder meer /touching inner rings/ en /invalid geometry/. Deze gebruiker heeft overigens ook op andere plaatsen dergelijke veranderingen gedaan, waaronder in Den Haag, maar daar zie ik zo snel geen problemen op de kaart. Willem Sonke [1] http://tools.geofabrik.de/osmi/?view=multipolygonlon=4.83140lat=52.41107zoom=13overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes On 27-12-11 15:30, Piet Smits wrote: Iemand heeft op 22 december deze way uit de relatie 1704 (die het zelfde lijkt als relatie Het IJ) gehaald. Wellicht had het daar iets mee te maken: http://www.openstreetmap.org/browse/relation/1704/history Bij de monding van de Ertshaven zie (of zag) je hetzelfde. grtz, Piet Op 27-12-2011 15:15, Floris Looijesteijn schreef: http://www.openstreetmap.org/browse/way/67559262 Ja, Willem1, die wijziging is te zien. Op dit moment wordt ie ook weer goed gerenderd. Renderbugje dus denk ik... Thanks all! Groet, Floris 2011/12/27 Floris Looijesteijno...@floris.nu: Volgens mij is die historie niet actueel. De weg waar ik het in m'n andere mailtje over heb, heb ik net enorm aan lopen trekken maar die staat nog steeds op de vorige editor z'n naam. Groet, Floris 2011/12/27 Maarten Deenmd...@xs4all.nl: On 2011-12-27 14:03, Floris Looijesteijn wrote: http://www.openstreetmap.org/?lat=52.37914lon=4.92726zoom=15layers=M Wie heeft er zin om even te kijken wat er aan de hand is? Vreemd. Dat stukje IJ is sinds juli 2010 niet aangeraakt: http://www.openstreetmap.org/browse/way/67559262 3dshapes:ggmodelk = 23 name = Het IJ natural = water source = 3dShapes Lijkt ok. Ik kan in Potlatch alleen niet controleren of de way helemaal correct is (closed en continuous). Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [Tagging] Rd -- Road
On Mon, Jan 2, 2012 at 7:37 AM, Mike N nice...@att.net wrote: On 12/29/2011 12:53 PM, Richard Welty wrote: i saw some failures of a script run over Nevada Iowa last year (not necessarily the script you're referring to): http://www.openstreetmap.org/?lat=42.02091lon=-93.44698zoom=15layers=M the script had converted E Ave to East Avenue, N Ave to North Avenue and S Ave to South Avenue, all of which were errors (Nevada avenue names are single letters.) This was not the referenced 'expand' script, which in my opinion *should* be run on the rest of the US. Unlike the rest of OSM work, handcrafted name expansion adds no value to the map database. There are errors - if I were to ever armchair-edit E Ave, I would almost certainly expand it to East Avenue, whereas the script has logic to prevent that error. Another argument against manual expansion is that it is not unheard of for newbies to come in behind and undo all expansion with abbreviations because that's what they are used to seeing on other maps - more wasted work. But I realize that current project opinion does not support automatic expansion. The best I can hope for is a JOSM plugin that automatically expands current edits or all ways in the current dataset download. I would like to see that discussion reopened too. Those abbreviated names are just odd -- and a half-executed correct script is just something we should not want to live with. Thanks Toby for pointing to your blog post, the visualization is very compelling. What makes you think that the current common opinion is against automatic expansion? What in particular were the complaints made against the fixbot? Can/should the fixbot be improved to take them into account? Also, I wonder where this was documented? I see no reference to this fixbot on http://wiki.openstreetmap.org/wiki/TIGER_fixup or http://wiki.openstreetmap.org/wiki/TIGER. -- martijn van exel geospatial omnivore 1109 1st ave #2 salt lake city, ut 84103 801-550-5815 http://oegeo.wordpress.com ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fwd: [Dutch] Nieuwjaarsborrel zo 22 januari
En is dit het Stilte gebied van Utrecht zodat we met z'n alle gezellig kunnen kletsen? Groet Robert -Oorspronkelijk bericht- From: Frank Steggink Sent: Monday, January 02, 2012 3:11 PM To: talk-nl@openstreetmap.org Subject: [OSM-talk-nl] Fwd: [Dutch] Nieuwjaarsborrel zo 22 januari Forward naar talk-nl. Locatie van Lofen in Utrecht: http://osm.org/go/0E6JMU6Wu--?m Dit is letterlijk onderaan de Domtoren, dus je kunt het niet missen ;) Groeten, Frank Original Message Subject: [Dutch] Nieuwjaarsborrel zo 22 januari Date: Mon, 02 Jan 2012 12:18:28 +0100 From: Just van den Broecke j...@justobjects.nl To: du...@lists.osgeo.org Beste Allemaal, Allereerst natuurlijk een gezond 2012 toegewenst en dat 2012 het jaar OSGeo.nl moge worden ! We beginnen in ieder geval al goed: Edward heeft een locatie (Lofen Utrecht) en meetup voor onze nieuwjaarsborrel samen met OpenStreetMap NL vastgesteld, zie http://www.meetup.com/OSGeoNL/events/46060652 en op onze Wiki. Aanmelden is niet verplicht maar wel handig. Deze OSGeo.nl Meetup http://www.meetup.com/OSGeoNL is verder algemeen dus kun je ook altijd gebruiken voor andere bijeenkomsten. Voorlopig is het BYOB (Buy Your Own Beer) maar mogelijk vinden we nog sponsoring. groeten, Just ___ Dutch mailing list du...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/dutch ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl --- Tekst ingevoegd door Panda GP 2012: Als het hier gaat om een ongevraagde e-mail (SPAM), klik dan op de volgende link om de e-mail te herclasseren: http://localhost:6083/Panda?ID=pav_395SPAM=truepath=C:\Windows\system32\config\systemprofile\AppData\Local\Panda%20Security\Panda%20Global%20Protection%202012\AntiSpam --- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Het IJ leeggepompt!
On 2-1-2012 12:07, Frank Steggink wrote: Ook hier zie ik geen fout in JOSM. Bij het opnieuw renderen van het gebied wordt de Westhaven nu wel goed gerenderd, behalve het stukje bij ADM. Misschien kan hier Lennard of iemand anders even naar kijken, aangezien hij het renderingproces beter begrijpt. Er zit blijkbaar iets fout. Misschien een Mapnik-update? Ik pas nu niks aan aan de data. Deze way zit niet in de mapnik db op tile.openstreetmap.nl en rendert bij ons dus ook niet. Aangezien deze way op osm.org ook niet rendert, vermoed ik dat deze niet goed in de diffs heeft gezeten. Dat kan ook verklaren waarom deze dan wel weer verschijnt als er een nieuwe update op die way gemaakt wordt. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-de] Konzept für straßenbegleitende Wege
Am 01.01.2012 23:17, schrieb Georg Feddern: Der 1.) Fall funzt tatsächlich nur, wenn der Router erkennen kann, dass der straßenbegleitende Radweg zu einer primary gehört. Einfacher Ansatz: Statt einem banalen yes könnte man als Würg-around die Straßenklasse angeben. Der Würg-around klappt aber auch nur, wenn es nur um die Straßenklasse geht. Wie schaut es aus, wenn alle Straßen mit einer maxspeed über 50 schlechter dastehen sollen oder mit mehr als 1 Spur je Richtung oder unbeleuchtet. Gleiches ist aber auch andersrum nötig. Bspw. nur dort langrouten, wenn der Radweg auch asphaltiert ist usw. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wochennotiz Nr. 76 ( 25.12.- 31.12.2011 )
Am 01.01.2012 16:38, schrieb Stephan Wolff: Am 01.01.2012 15:35, schrieb Gehling Marc: Hallo, auch 2012 wollen wir euch mit Infos rund um OSM versorgen. Vielen Dank an das Wochennotizteam für die sehr nützlichen Zusammenfassungen aus der OSM-Welt. Einen Verbesserungsvorschlag habe ich noch. Könntet ihr die jeweils neuen Abstimmungen zum tagging unter Category:Proposed features Voting sowie die angenommenen tags mit aufnehmen? Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hallo Stephan! Nun ich muss gestehen, dass ich zwar vieles für die WN und auch für das Wiki mache, aber mich bei allen Sachen bzgl. proposals halte ich mich raus, da habe ich zu schlechte Erfahrungen gesammelt. Ein anderer Aspekt ist dann auch die Zeit, irgendwo muss ich einfach auch Stop sagen :) Mich würde es aber sehr freuen, wenn unsere Leser uns dabei unterstützen könnten und Proposals/wiss. Artikel/Artikel über OSM/... im Wiki verlinken könnten. Leider ist das ganze Proposal Verfahren ziemlich uneindeutig und unorganisiert, aber das hatte Frederik ja auch schon moniert ;) Frohes Neues Matthias (user:!i!) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Benennung von Ferienanlagen
hi ! in Feriengebieten gibt es oftmals Anlagen aus mehreren Gebäuden die einen gemeinsamen Namen haben - wie würde Ihr diese zuordnen ? Gruß jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Benennung von Ferienanlagen
relation: type=site http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site gruss walter - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/Benennung-von-Ferienanlagen-tp7143444p7143518.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] [OSM-talk] Wrong weblink/page on wiki home page: Gemeinschafts-Portal (DE:Mapping_projects?)
Hi Erik Thanks for the hint. I also thought about that. But I am very reluctant to use redirects to compensate mistakes. In this case it's obvious that the original URL (and name!) should be corrected. Is anybody here who is able to change the navigation link? Yours, Stefan 2012/1/1 Erik Johansson e...@kth.se: On Sun, Jan 1, 2012 at 12:55, Stefan Keller sfkel...@gmail.com wrote: Who is caring for the german translation of the current OSM wiki? In the german GUI translation of the wiki homepage (Mediawiki) there seems to be a void weblink: In the navigation panel, the weblink Gemeinschafts-Portal points to [[OpenStreetMap:Gemeinschafts-Portal]] which is an empty page. I think this should point to [[DE:Mapping_projects]]. If this is the intended target URL then I pose the question if the Gemeinschafts-Portal should'nt be translated as Gemeinschaftsprojekte? In Swedish it links to: OpenStreetMap:Deltagarportalen which is also blank. But you can add a redirect, e.g. #redirect[[DE:Mapping_projects]] on OpenStreetMap:Gemeinschafts-Portal and you should get what you want. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wochennotiz Nr. 76 ( 25.12.- 31.12.2011 )
Hallo, On 01/01/12 16:38, Stephan Wolff wrote: Einen Verbesserungsvorschlag habe ich noch. Könntet ihr die jeweils neuen Abstimmungen zum tagging unter Category:Proposed features Voting sowie die angenommenen tags mit aufnehmen? Ich finde, das wuerde dem Proposal/Abstimmungsprozess eine Bedeutung beimessen, die ihm nicht gebuehrt. Waere also eher dagegen. Alle Naslang werden obskure Tags durchgevotet, die niemand nutzt und niemand brauchen kann (ich sag nur: access:parentcustomer=designated). Der durchschnittliche Blog-Leser weiss womoeglich nicht, dass diese Abstimmungen keinerlei Relevanz fuer OSM haben und koennte durch eine Erwaehnung in der Wochennotiz irrtuemlich zu der Annahme kommen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Licence als WMS einbinden in JOSM
Hi !
wenn ich als Bilddienst-URL folgendes stehen habe:
tms:http://www.toolserver.org/tiles/bw-mapnik/{zoom}/{x}/{y}.jpg
dann bekomme ich nur eine SW-Mapnik-Karte ohne Kennzeichnungen für die
betreffenden Elementen ?
Gruß Jan :-)
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JSOM: Versionsprotokoll
Hi ! in JOSM kann man im Versionspotokoll zwei Knöpfchen A und B setzen. Kann mir einer sagen was der unterschied ist ?? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Licence als WMS einbinden in JOSM
Das ist nur zum wissen wo gelbe und rote Elementen zu finden sind. Dann
musst du natürlich auch noch die Daten selbst runterladen und dann kannst
du noch das JOSM plugin benutzen um die Elemente selber zu merken.
Polyglot
2012/1/2 Jan Tappenbeck o...@tappenbeck.net
Hi !
wenn ich als Bilddienst-URL folgendes stehen habe: tms:
http://www.toolserver.org/**tiles/bw-mapnik/{zoom}/{x}/{y}**.jpghttp://www.toolserver.org/tiles/bw-mapnik/%7Bzoom%7D/%7Bx%7D/%7By%7D.jpg
dann bekomme ich nur eine SW-Mapnik-Karte ohne Kennzeichnungen für die
betreffenden Elementen ?
Gruß Jan :-)
__**_
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Licence als WMS einbinden in JOSM
überleg mal, was bw-mapnik wohl bedeuten könnte. ich deute das als BlackWhite Mapnik-Layer - und das ist genau das, was du ja bekommst. Du must dich hier zum richtigen Layer-Namen durchhangeln. Eventuell weiss jemand mehr als ich. Jedenfalls bist du kurz vor dem Ziel. Gruss Walter - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/Geofabrik-Licence-als-WMS-einbinden-in-JOSM-tp7142392p7144159.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] JSOM: Versionsprotokoll
hi jan, such dir ein OSM-Objekt mit mehreren Versionen und klick mal die Knöpfchen - dann sollte es eigentlich klar sein. Gruss Walter - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/JSOM-Versionsprotokoll-tp7144130p7144166.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] Geofabrik-Licence als WMS einbinden in JOSM
tms[18]:http://{switch:a,b,c}.
www.toolserver.org/tiles/bw-mapnik/{zoom}/{x}/{y}.png
ist der richtige URL. Die musst du unten einstüfen, nich oben wie im Video.
Bei mir gebt das kein Black White, sondern gelb und rote andeutungen wo
die Nodes und Wege sich befinden.
Polyglot
2012/1/2 Jan Tappenbeck o...@tappenbeck.net
Hi !
wenn ich als Bilddienst-URL folgendes stehen habe: tms:
http://www.toolserver.org/**tiles/bw-mapnik/{zoom}/{x}/{y}**.jpghttp://www.toolserver.org/tiles/bw-mapnik/%7Bzoom%7D/%7Bx%7D/%7By%7D.jpg
dann bekomme ich nur eine SW-Mapnik-Karte ohne Kennzeichnungen für die
betreffenden Elementen ?
Gruß Jan :-)
__**_
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Licence als WMS einbinden in JOSM
Hallo,
On 01/02/12 17:23, Jo wrote:
tms[18]:http://{switch:a,b,c}.
www.toolserver.org/tiles/bw-mapnik/{zoom}/{x}/{y}.png
ist der richtige URL. Die musst du unten einstüfen, nich oben wie im Video.
Bei mir gebt das kein Black White, sondern gelb und rote andeutungen wo
die Nodes und Wege sich befinden.
Wie kommt denn die Toolserver-Black-and-White-Map hier ins Spiel, ich
dachte, Jan wollte den OSMI-Lizenzwechsel-View?
Den laedt man am besten, wie es auf der Seite
http://wiki.openstreetmap.org/wiki/Remapping/License_Change_View_on_OSM_Inspector
bzw. dann
http://wiki.openstreetmap.org/wiki/OSM_Inspector/WxS
dokumentiert ist, als WMS. Bei JOSM geht man auf das + im
Preferences-Dialog und im Tab WMS gibt man als Service URL ein
http://tools.geofabrik.de/osmi/view/wtfe/wxs?
ein Klick auf Get Layers ermoeglicht dann die Auswahl des Geofabrik
Tools: OSM Inspector (WTFE)-Layers.
Alternativ kann man den Layer auch als Tileserver ansprechen, das ist
ebenfalls auf der Seite
http://wiki.openstreetmap.org/wiki/Remapping/License_Change_View_on_OSM_Inspector
unten erklaert, dazu nimmt man dann den URL
http://tools.geofabrik.de/osmi/tiles/wtfe/{zoom}/{x}/{y}.png
Bye
Frederik
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Licence als WMS einbinden in JOSM
Da habe ich warscheinlich Schuld, etwas falsch gemacht. Entschuldigung!
Jo
2012/1/2 Frederik Ramm frede...@remote.org
Hallo,
On 01/02/12 17:23, Jo wrote:
tms[18]:http://{switch:a,b,c}.
www.toolserver.org/tiles/bw-**mapnik/{zoom}/{x}/{y}.pnghttp://www.toolserver.org/tiles/bw-mapnik/%7Bzoom%7D/%7Bx%7D/%7By%7D.png
ist der richtige URL. Die musst du unten einstüfen, nich oben wie im
Video.
Bei mir gebt das kein Black White, sondern gelb und rote andeutungen wo
die Nodes und Wege sich befinden.
Wie kommt denn die Toolserver-Black-and-White-Map hier ins Spiel, ich
dachte, Jan wollte den OSMI-Lizenzwechsel-View?
Den laedt man am besten, wie es auf der Seite
http://wiki.openstreetmap.org/**wiki/Remapping/License_Change_**
View_on_OSM_Inspectorhttp://wiki.openstreetmap.org/wiki/Remapping/License_Change_View_on_OSM_Inspector
bzw. dann
http://wiki.openstreetmap.org/**wiki/OSM_Inspector/WxShttp://wiki.openstreetmap.org/wiki/OSM_Inspector/WxS
dokumentiert ist, als WMS. Bei JOSM geht man auf das + im
Preferences-Dialog und im Tab WMS gibt man als Service URL ein
http://tools.geofabrik.de/**osmi/view/wtfe/wxshttp://tools.geofabrik.de/osmi/view/wtfe/wxs
?
ein Klick auf Get Layers ermoeglicht dann die Auswahl des Geofabrik
Tools: OSM Inspector (WTFE)-Layers.
Alternativ kann man den Layer auch als Tileserver ansprechen, das ist
ebenfalls auf der Seite
http://wiki.openstreetmap.org/**wiki/Remapping/License_Change_**
View_on_OSM_Inspectorhttp://wiki.openstreetmap.org/wiki/Remapping/License_Change_View_on_OSM_Inspector
unten erklaert, dazu nimmt man dann den URL
http://tools.geofabrik.de/**osmi/tiles/wtfe/{zoom}/{x}/{y}**.pnghttp://tools.geofabrik.de/osmi/tiles/wtfe/%7Bzoom%7D/%7Bx%7D/%7By%7D.png
Bye
Frederik
__**_
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wochennotiz Nr. 76 ( 25.12.- 31.12.2011 )
Am 02.01.2012 15:12, schrieb Frederik Ramm: Hallo, On 01/01/12 16:38, Stephan Wolff wrote: Einen Verbesserungsvorschlag habe ich noch. Könntet ihr die jeweils neuen Abstimmungen zum tagging unter Category:Proposed features Voting sowie die angenommenen tags mit aufnehmen? Ich finde, das wuerde dem Proposal/Abstimmungsprozess eine Bedeutung beimessen, die ihm nicht gebuehrt. Waere also eher dagegen. Alle Naslang werden obskure Tags durchgevotet, die niemand nutzt und niemand brauchen kann (ich sag nur: access:parentcustomer=designated). Der durchschnittliche Blog-Leser weiss womoeglich nicht, dass diese Abstimmungen keinerlei Relevanz fuer OSM haben und koennte durch eine Erwaehnung in der Wochennotiz irrtuemlich zu der Annahme kommen. +1 Wenn die Redaktion meint, dass es aber einen Vorschlag gibt, der für die Masse interessant sein könnte, sollte dieser auch einen Platz in der Wochennotiz finden. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wochennotiz Nr. 76 ( 25.12.- 31.12.2011 )
Am 02.01.2012 um 18:42 schrieb Henning Scholland: Am 02.01.2012 15:12, schrieb Frederik Ramm: Hallo, On 01/01/12 16:38, Stephan Wolff wrote: Einen Verbesserungsvorschlag habe ich noch. Könntet ihr die jeweils neuen Abstimmungen zum tagging unter Category:Proposed features Voting sowie die angenommenen tags mit aufnehmen? Ich finde, das wuerde dem Proposal/Abstimmungsprozess eine Bedeutung beimessen, die ihm nicht gebuehrt. Waere also eher dagegen. Alle Naslang werden obskure Tags durchgevotet, die niemand nutzt und niemand brauchen kann (ich sag nur: access:parentcustomer=designated). Der durchschnittliche Blog-Leser weiss womoeglich nicht, dass diese Abstimmungen keinerlei Relevanz fuer OSM haben und koennte durch eine Erwaehnung in der Wochennotiz irrtuemlich zu der Annahme kommen. +1 Wenn die Redaktion meint, dass es aber einen Vorschlag gibt, der für die Masse interessant sein könnte, sollte dieser auch einen Platz in der Wochennotiz finden. So haben wir es bisher auch gemacht. Wenn viel darüber diskutiert wurde oder unser subjektives Relevanzkriterium erfüllt war, hat es Platz gefunden. Mfg Marc ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wrong weblink/page on wiki home page: Gemeinschafts-Portal (DE:Mapping_projects?)
Hi Tom 2012/1/2 Tom Hughes t...@compton.nu wrote: It's a wiki - anybody can change it. At least I don't think that page is protected at all. I think this is the one you want: http://wiki.openstreetmap.org/wiki/MediaWiki:Portal-url/de I'm pretty sure you need admin rights for this links (these pages are locked for users). And changing the sidebar/navigation you even need sys admin rights (see http://www.mediawiki.org/wiki/Manual:Interface/Sidebar ). So do you know somebody who can take action? Having looked once again at the sidebar/navigation, there are even more translation issues at least for the german interface languages de and de_ch. Currently sidebar/navigation loos like this (in de and de_ch as interface language): Hauptseite The map Gemeinschafts-Portal ... Donations But it should become something like this: Hauptseite Die Karte Mapping-Projekte ... Spenden Yours, Stefan 2012/1/2 Tom Hughes t...@compton.nu: On 02/01/12 12:32, Stefan Keller wrote: Thanks for the hint. I also thought about that. But I am very reluctant to use redirects to compensate mistakes. In this case it's obvious that the original URL (and name!) should be corrected. Is anybody here who is able to change the navigation link? It's a wiki - anybody can change it. At least I don't think that page is protected at all. I think this is the one you want: http://wiki.openstreetmap.org/wiki/MediaWiki:Portal-url/de Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenGeoDB eingestellt
Lieber Sven, liebe Mapper Wie schon an anderer Stelle erwähnt, würde es meiner Erfahrung nach der OSM Datenbank sehr gut tun, wenn man die OpenGeoDB Tags löschen würde. Wenn's gut gemacht ist, wieso auch nicht automatisch? Bisher hatte ich mich davor gescheut. Aber wenn nun auch Sven mit Löschen einverstanden ist - wenn ich ihn richtig verstehe -, steht dem nichts mehr im Wege. Dabei habe ich nichts gegen OpenGeoDB (im Gegenteil) und auch nichts gegen solche Imports (wenn sie gut laufen :-). Die OpenGeoDB-tags jedenfalls haben bis auf wenige ihren Dienst getan und sind nun nur noch Ballast für die tag-Liste pro Node. Zu den Löschkandidaten gehören m.E. u.a. folgende: opengeodb:lat, opengeodb:lon, openGeoDB:name, openGeoDB:type,openGeoDB:is_in, openGeoDB:layer, openGeoDB:version, openGeoDB:sort_name, openGeoDB:auto_update, openGeoDB:is_in_loc_id, openGeoDB:postal_codes, openGeoDB:community_identification_number Was man behalten könnte ist: openGeoDB:loc_id population = value aus openGeoDB:population=value, falls tag population nicht schon vorhanden source:population=OpenGeoDB oder - etwas vorsichtiger: openGeoDB:loc_id openGeoDB:population Gruss, Stefan Am 4. Dezember 2011 19:30 schrieb Sven Anders s...@anders-hamburg.de: Am 04.12.2011 16:25, schrieb Andreas Hubel: Die Daten gibt es weiter unter http://fa-technik.adfc.de/code/opengeodb/ zum Download, bearbeiten kann man sie unter http://fa-technik.adfc.de/code/opengeodb.pl Der Unterschied zu OSM ist eigentlich nur die freiere Lizenz und die Bereitstellung als CSV. Am 02.12.2011 um 13:26 schrieb Michael Neumann: Was bedeutet das fuer OSM und die OpenGeoDB-Tags? Gar nichts. Man hat die Tags damals glaube ich nur genommen, damit klar ist woher die Daten kommen und das man nicht lange diskutieren muss welche Tags nun am besten geeignet sind. Wir hatten damit dann auf einen Schlag so ziemlich jeden Ort(steil) in Deutschland (und anderen Ländern) bei uns in der DB. Ich hatte damals den Import gemacht und gedacht, man könnte das regelmäßig wiederholen. Da aber bereits beim Import nicht alles glatt ging, würde ich heute keinen neu Import/Update mehr machen wollen. Wenn überhaupt eher eine automatische Auswertung, und der Mapper kann es dann geradeziehen. Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] IT:Tag:amenity=college
2011/12/31 Fabri erfab...@gmail.com: Propongo di usare amenity=university per le università e amenity=school per le altre scuole (tutti i tipi, comprese le scuole superiori) +1 +1 Per me si può anche lasciar perdere amenity=college. Dunque tradurlo su Josm con: College (non in Italia) A voler salvare amenity=college, lo si potrebbe usare per quelle scuole post-maturità che non rilasciano lauree, come ad es. alcune scuole di teatro, di design ecc. Ciao Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] R: Re: R: Re: questione licenza?
Concordo perchè aspettare? Prima si fa prima si sistema:) Per esempio a Venezia ho messo il nome di palazzi storici con le vecchie foto ora con le nuove si farà tutto più preciso Per gli altri interventi almeno per le statali se si trovano prima rimapparle...anche se dubito i dati vengano cancellati per evitare possibili ricorsi, uno li ha fatti accettando la vecchia licenza è un dato pregressoscusate ma se dovesse cambiare la licenza ogni anno che si fa? Non ha senso! Messaggio originale Da: edoa...@edoardomarascalchi.it Data: 01/01/2012 16.42 A: openstreetmap list - italianotalk-it@openstreetmap.org Ogg: Re: [Talk-it] R: Re: questione licenza? Perché aspettare per Venezia. Se la situazione è tragica, spianate e ripartite dalla CTR. Magari avvisate gli utenti che ci han lavorato prima (io per esempio). :D Edoardo Il giorno 01 gennaio 2012 16:27, Luca 'remix_tj' Lorenzetto lorenzetto.l...@gmail.com ha scritto: 2012/1/1 Sky One sky...@skyone.it: Come ha chiesto qualcuno, che fare? Eliminare e rimappare? Aspettare? Noi veneti per esempio attendiamo l'arrivo della famosa pulizia che ci permetterebbe finalmente di riprendere in mano venezia (attualmente in uno stato pietoso). Quindi io consiglio di aspettare. Così poi per certo si potrà vedere dove intervenire. -- E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) Internet è la più grande biblioteca del mondo. Ma il problema è che i libri sono tutti sparsi sul pavimento John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , lorenzetto.l...@gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- Edoardo Marascalchi skype: asca_edom ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] il mio comune usa google maps
Il 20 dicembre 2011 10:58, Luca Delucchi lucadel...@gmail.com ha scritto: Il giorno 10/dic/2011 18.43, Ruggero giurr...@gmail.com ha scritto: Secondo voi questo documento [1] č legale? Posso usare i dati (numero di posti auto per esempio)? Cosa posso scrivere al comune? Ci sono novità? no, scusate, sono straimpegnato (trasloco, nuovo lavoro), ma prometto che lo farò Ruggero Ciao Luca http://www.lucadelu.org http://gis.cri.fmach.it/delucchi ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] mappa dei parcheggi
per chi non e' iscritto sulla ML OSM-talk per il nuovo anno e' stata aggiornata la mappa dei parcheggi (ed io non sapevo manco che ci fosse) http:.//parking.openstreetmap.de Il rendering si adatta ai nuovi tag e visualizza anche dove si trovano i parchimetri Maggiori dettagli qui http://lists.openstreetmap.org/pipermail/talk/2012-January/061416.html l'invito e' quello di migliorare questa informazione :) -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] mappa dei parcheggi
Il 02 gennaio 2012 20:48, Maurizio Napolitano napoo...@gmail.com ha scritto: per chi non e' iscritto sulla ML OSM-talk per il nuovo anno e' stata aggiornata la mappa dei parcheggi (ed io non sapevo manco che ci fosse) http:.//parking.openstreetmap.de Il rendering si adatta ai nuovi tag e visualizza anche dove si trovano i parchimetri Maggiori dettagli qui http://lists.openstreetmap.org/pipermail/talk/2012-January/061416.html l'invito e' quello di migliorare questa informazione :) Bella! Queste iniziative aiutano ad incentivare la mappatura di alcune feature. Indubbiamente, quelle che vengono in qualche modo usate sono quelle più popolari... Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-dk] Anbefalede hastighedsbegrænsninger?
Min hensigt er at gøre noget mere ud af at angive hastighedsbegrænsninger på vejnettet, men jeg er løbet ind i flg. problem: Hvordan tagger man veje med dette vejskilt - http://www.google.dk/imgres?q=e53+fartd%C3%A6mpninghl=dabiw=1680bih=935tbm=ischtbnid=CDtz0e_6fsvr2M:imgrefurl=http://www.teoriundervisning.dk/tavler/tavle-oversigt/oplysningstavlerdocid=kVbxoNcBrG4amMimgurl=http://www.teoriundervisning.dk/assets/image/roadsigns/E53.gifw=354h=442ei=LHoBT46pNcLGtAbwipXRDAzoom=1iact=hcvpx=172vpy=119dur=859hovh=251hovw=201tx=137ty=161sig=107531955799100510449page=1tbnh=130tbnw=104start=0ndsp=47ved=1t:429,r:0,s:0 Runde rød/hvid skilte er påbud, og firkantede blå skilte er anbefalinger. dvs: Det er tilladt at køre op til 50 km/t, men det er anbefalet at man holder sig til 30 km/t (det blå anbefalings-skilt er som regel suppleret af vejbump eller andre foranstaltninger, der er designet til at blive passeret med den på anbefalingsskiltet angivne hastighed.) Er der brug for en ny tag - speed_recommended: ? Eller skal vi benytte os af allerede eksisterende tags og tagge vejen/liniestykket som: maxspeed:50 traffic_calming:30 Andre forslag? venlig hilsen Rune Kruse aka Kruneruse ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Anbefalede hastighedsbegrænsninger?
Hej Rune, Du finder næsten svaret på den danske del af wiki'en [1]. Pt. er alle skiltede hastighedsbegrænsninger markeret som maxspeed=*, source:maxspeed=sign. Man kan argumentere for, at opslyningstavlen bør gives source:maxspeed=zone, og source:maxspeed=sign kun bør gælde for forbudstavlen, men det er reelt en smagssag. Hastighedsbegrænsningerne kan stort set kun bruges til routing, og i den sammenhæng giver oplysningstavler og forbudstavler samme information, da du efter færdselslovens intention skal færdes efter forholdene. På den tyske del af wiki'en er der forslag til mere komplicerede tagging schemes, men som du hurtigt vil se er de overkomplicerede ift. det vi vinder. [1] - http://wiki.openstreetmap.org/wiki/Da:Key:maxspeed Med venlig hilsen Rasmus Vendelboe 2012/1/2 Rune Kruse r...@krusedulle.net Min hensigt er at gøre noget mere ud af at angive hastighedsbegrænsninger på vejnettet, men jeg er løbet ind i flg. problem: Hvordan tagger man veje med dette vejskilt - http://www.google.dk/imgres?q=e53+fartd%C3%A6mpninghl=dabiw=1680bih=935tbm=ischtbnid=CDtz0e_6fsvr2M:imgrefurl=http://www.teoriundervisning.dk/tavler/tavle-oversigt/oplysningstavlerdocid=kVbxoNcBrG4amMimgurl=http://www.teoriundervisning.dk/assets/image/roadsigns/E53.gifw=354h=442ei=LHoBT46pNcLGtAbwipXRDAzoom=1iact=hcvpx=172vpy=119dur=859hovh=251hovw=201tx=137ty=161sig=107531955799100510449page=1tbnh=130tbnw=104start=0ndsp=47ved=1t:429,r:0,s:0 Runde rød/hvid skilte er påbud, og firkantede blå skilte er anbefalinger. dvs: Det er tilladt at køre op til 50 km/t, men det er anbefalet at man holder sig til 30 km/t (det blå anbefalings-skilt er som regel suppleret af vejbump eller andre foranstaltninger, der er designet til at blive passeret med den på anbefalingsskiltet angivne hastighed.) Er der brug for en ny tag - speed_recommended: ? Eller skal vi benytte os af allerede eksisterende tags og tagge vejen/liniestykket som: maxspeed:50 traffic_calming:30 Andre forslag? venlig hilsen Rune Kruse aka Kruneruse ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
[Talk-dk] OpenStreetMap i Comon i dag
Hej alle sammen OpenStreetMap er så blevet omtalt i et dansk medie i dag, nemlig hos Comon Det er vedr. at nogle udenlandske webservices har skiftet fra Google Maps til OpenStreetMap baseret kort lavet af cloudmade, mapquest open tile. Dette skifte skyldes at Google Map nu tager penge for dem der bruger deres API meget. http://www.comon.dk/art/205317/google-vil-tjene-penge-paa-sine-kort Nu mangler vi bare at et større dansk website skifter til noget OSM baseret kort og af den vej - flere kommer til at bruge OSM i en eller anden form. /Søren Johannessen ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] OpenStreetMap i Comon i dag
DMI er på vej med deres verdensvejr, se http://www.dmi.dk/dmi/index/verden.htm Det var en god og positiv nyhed du fandt frem der Erik. Ser frem til DMIs løsning /Søren ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Anbefalede hastighedsbegrænsninger?
Vi havde denne diskussion tilbage i april [1]. De blå skilte bør ikke lægges til grund for maxspeed=*, men der kom ingen afklaring på hvordan man så registrerer anbefalet hastighed. /Lars [1] http://lists.openstreetmap.org/pipermail/talk-dk/2011-April/001439.html ff 2012/1/2 Morten Kjeldgaard m...@bioxray.dk: On 02/01/2012, at 10.52, Rune Kruse wrote: Runde rød/hvid skilte er påbud, og firkantede blå skilte er anbefalinger. dvs: Det er tilladt at køre op til 50 km/t, men det er anbefalet at man holder sig til 30 km/t (det blå anbefalings-skilt er som regel suppleret af vejbump eller andre foranstaltninger, der er designet til at blive passeret med den på anbefalingsskiltet angivne hastighed.) Er der brug for en ny tag - speed_recommended: ? Som det tidligere er nævnt her på listen, er hastighedsgrænsen f.eks. i byområder en _maksimums_ hastighed. Under _alle_ omstændigheder skal der køres efter forholdene. Man kan derfor argumentere, at når politiet har opsat zone-skilte der angiver 30 km/t, så er dette den maximale hastighed der kan køres med efter forholdene det pågældende sted. Jeg ville nok betænke mig på at ræse forbi en politibil med 50 km/t i en 30 km/t zone... Jeg vil meget advare mod at OSM anbefaler maxhastigheder nogen steder. -- Morten ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-ee] Kaardiserver - tehnilisi detaile ainult friikidele
Kas meil teoreetiliselt oleks võimalik saada juurde veel üks kast (ja siis veel) millega saaks kuidagi hakata planeeti fragmentideks tükeldama? http://en.wikipedia.org/wiki/Scalability#Scale_horizontally_.28scale_out.29 mv Ühel kenal päeval, E, 02.01.2012 kell 10:49, kirjutas Jaak Laineste: Juba vana aasta lõpuks (vähem kui 3 päevaga, mis on planeedi osm2pgsql jaoks kiire aeg) sai aga kettaruum täis. Seega et meie 2x150G (2 ketastele ei mahu planeet ära. Kui täpne olla, siis andmed veel napilt ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee
Re: [Talk-ee] Kaardiserver - tehnilisi detaile ainult friikidele
2.01.2012 12:55, Margus Värton kirjutas: Ma arvan, et Jaagu pakutu on praegu reaalsem stsenaarium. Me võiksime alanud aastasse planeerida andmebaasiketaste asendamise suurematega, kuid ma ei näe selleks praegu eelarvet. 300GB 15k SAS kettad ei ole liiga odavad. Vaatasin kettapakkumisi Markitist väikese varuga - 600 GB 15000rpm SAS-2 Seagate Cheetah kettad maksavad 407 euri koos käibemaksuga. Polegi hullult palju. Väga vähe kah ei ole, aga sellises ulatuses, mille saaks kenasti 1-2 hea toetaja abiga ära teha. Sellisel juhul saaks siis olemasolevad kettad testmasinasse tõsta ning sellest saaks üsna kiire kettasüsteemiga testmasin. - M - ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee
Re: [Talk-ee] Kaardiserver - tehnilisi detaile ainult friikidele
On 02.01.2012, at 15:39, Margus Värton wrote: 2.01.2012 12:55, Margus Värton kirjutas: Ma arvan, et Jaagu pakutu on praegu reaalsem stsenaarium. Me võiksime alanud aastasse planeerida andmebaasiketaste asendamise suurematega, kuid ma ei näe selleks praegu eelarvet. 300GB 15k SAS kettad ei ole liiga odavad. Vaatasin kettapakkumisi Markitist väikese varuga - 600 GB 15000rpm SAS-2 Seagate Cheetah kettad maksavad 407 euri koos käibemaksuga. Polegi hullult palju. Väga vähe kah ei ole, aga sellises ulatuses, mille saaks kenasti 1-2 hea toetaja abiga ära teha. Sellisel juhul saaks siis olemasolevad kettad testmasinasse tõsta ning sellest saaks üsna kiire kettasüsteemiga testmasin. Kokku siis 800? Umbes 900 eest saaks Inteli 600G 320-seeria SSD, mis oleks veel palju (10x?) kiirem ja peaks mahu osas veel mõnda aega välja vedama. OSM tileserveris on selline ketas, aga ma ei tea mida ta seal õigupoolest teeb. Andmebaas on seal ikka stripetud (raid-10) SAS-ide peal. Sponsorit oleks vaja ikkagi. Anyway, ma alustasin kerneli uuendusega, mispeale server tundub mitte üles tulevat. Remote consol on olemas seal aga nõuab nii spetisifilist os/brauseri/java versioonide komplekti et mul pole õnnestunud toimivat varianti leida :( Jaak ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee
Re: [Talk-ee] Kaardiserver - tehnilisi detaile ainult friikidele
2.01.2012 16:06, Jaak Laineste kirjutas: Kokku siis 800? Umbes 900 eest saaks Inteli 600G 320-seeria SSD, mis oleks veel palju (10x?) kiirem ja peaks mahu osas veel mõnda aega välja vedama. OSM tileserveris on selline ketas, aga ma ei tea mida ta seal õigupoolest teeb. Andmebaas on seal ikka stripetud (raid-10) SAS-ide peal. Sponsorit oleks vaja ikkagi. Tõenäoliselt kasutatakse seal SSD-d kiire vahemäluna. Aga tõsi on, et nii väikese hinnavahe juures on SSD parem lahendus. - M - ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee
Re: [Talk-ee] Kaardiserver - tehnilisi detaile ainult friikidele
Meil pole kasutatavustki, rääkimata statistikast. Andy Allani (opencyclemap jms) jutust jäi kõrva tema tõdemus, et enamusi tile-sid päritakse üks kord ja siis enam mitte kunagi, cachemise jaoks raske olukord. On vaid mõnisada MB madala zoomiga tilesid mida korduvpäritakse.Anyway, mu suurepärane idee "sudo apt-get installlinux-image-3.0.0-14-generic;reboot -n" päädis sellega et server ei tule üles ja konsoolilt vaatab pärast linuxi valimist attachitud pilt. Mu oskused said otsa. Remote console ühendust ei saa ka täielikult käima, ilmselt tuleb serveriruumi minna. Appi!JaakOn 02.01.2012, at 17:06, Margus Väli wrote:SSD kirjutamine on aeglasem. Ta tasub end ära kui on palju tõilasid,meil siin neid vist pole eriti, st. enamik rahva nõutud pilte kettaltmahuks ju lausa linuxi mälupuhvrisse ära mis on veel kiirem sest onopmälu? Jaak...on sul statistikat tilede kasutatavuse kohta ja paljuneid nõutumaid mahult on?mvÜhel kenal päeval, E, 02.01.2012 kell 16:33, kirjutas Margus Värton:2.01.2012 16:06, Jaak Laineste kirjutas:Kokku siis 800? Umbes 900 eest saaks Inteli 600G 320-seeria SSD, mis oleks veel palju (10x?) kiirem ja peaks mahu osas veel mõnda aega välja vedama. OSM tileserveris on selline ketas, aga ma ei tea mida ta seal õigupoolest teeb. Andmebaas on seal ikka stripetud (raid-10) SAS-ide peal. Sponsorit oleks vaja ikkagi.Tõenäoliselt kasutatakse seal SSD-d kiire vahemäluna. Aga tõsi on, et nii väikese hinnavahe juures on SSD parem lahendus.- M -___Talk-ee mailing listTalk-ee@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ee___Talk-ee mailing listTalk-ee@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ee___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee
[Talk-at] Hausnummern, Kennzeichnen des Zuganges (Gartentüre) zu einem Gebäude
Hallo, danke nochmals für alle Hinweise bezüglich des Taggings von Hausnummern. Ich wohne in einem ländlichen Gebiet, wo Einfamilien-Häuser typischerweise auf relativ großen Grundstücken stehen. Als Besucher, Botendienst oder Taxifahrer sucht man hier die Gartentüre, bei der im Normalfall auch Klingelknopf und Briefkasten gefunden werden können. Ich würde daher gerne diesen Punkt als Zugangspunkt zum Haus/zur Adresse taggen. Das OSM-Adress-Tagging bezieht sich aber immer auf das Gebäude selbst, sodass die Zugangsinformation hier nicht gut eingebracht werden kann. Unter http://wiki.openstreetmap.org/wiki/Proposed_features/De:Hausnummern bei Angabe einer besonderen Zufahrt wird zwar eine Möglichkeit beschrieben, mittels einer Relation einen Zugangspunkt anzubinden, dies scheint mir aber eher für einzelne, besondere Fälle gedacht, nicht für alle Häuser, die von Garten umgeben sind. Gibt es eine Möglichkeit, einen derartigen Zugangspunkt mit Adresse zu taggen? LG, Christoph ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-cz] UIR-ZSJ - části obce, základní sídelní jednotky
hanoj napsal(a): *** postup je popsan vyse, funkce vztahu mezi rozlohou a poctem obyvatel sidla poskytnu na pozadani. O to bych určitě měl zájem. Ja se snazim vybrat nejjednoduseji ty casti UIR-ZSJ, ktere lze s vysokou uspesnosti importovat ve velkych kusech (rekneme okresech) a to COBE.DBF a OBCE.DBF. U ZSJ je zvysena mira selekce nutna, tudiz chapu potrebnost poloautomatickeho postupu. Máš pravdu, že tenhle přístup by měl umožnit importovat OBCE a COBE automaticky s přiměřeným počtem chyb. A potom můžem pokračovat s opravami a poloautomatickým doplněním ZSJ. Ad Alternativní systém tagů (Hanoj): Jestli jsem to dobře pochopil, tak se oba návrhy moc neliší... Já jsem to jen popisoval z pohledu mapera, ty z pohledu dat v UIR-ZSJ. Asi zbývá doladit pár věcí: 1) Jak už jsem psal, dataset MCAST (dělení statutárních měst) bych vynechal - jsou tam většinou jen očíslované městské části, a ty co nějaké rozumné jméno mají se dublují s COBE... protože dělení na městské části a části obce jsou zhruba na stejné úrovni. 2) suburb Původně jsem navrhoval takto označit všechny části obce uvnitř sídla city/town/village. Není mi přesně jasné, pro co navrhuješ ty - jen čtvrti ve statutárních městech? Nebo všechny části obce uvnitř sídla town/city (k tomu se teď přikláním já)? 3) isolated_dwelling by měla být samota - problém je, že jestli se jedná o samotu nejde vykoukat jen z počtu obyvatel, možná by to šlo z počtu domů, ale to bysme museli přibrat ještě nějaký další rejstřík ČSÚ. --- A ještě jednou věcí asi trochu rozdmýchám diskuzi - kam a jak doplnit tag population. Imho má smys údaj doplňovat jen na samostatná sídla (tj. city/town/village/hamlet). Ale mnohem důležitější je, jaký údaj - protože aby to k něčemu bylo musí to být porovnatelná čísla. Podobně jako není možné vzít všechny části obce a prohlásit je za place=suburb, není možné slepě vzít údaj o počtu obyvatel a plácnout ho na odpovídající node. Můj návrh je: 1) jedná-li se o část obce: obyvatelstvo z COBE. 2) jedná-li se pouze o základní sídelní jednotku: obyvatelstvo ze ZSJ. 3) jedná-li se o administrativní centrum obce: obyvatelstvo z OBCE - součet obyvatelstva částí obce z kroku 1. Tehnle postup zajišťuje několik věcí: - Součet hodnot tagu population ze všech sídel na území obce bude zhruba[*] odpovídat celkovému počtu obyvatel v dané obci. - Jednotlivé hodnoty jsou porovnatelné a reprezentují to, co se od nich očekává - počet obyvatel daného sídla. - Funguje to jak na obce vzniklé složením několika vesniček (obec je většinou pojmenovaná po jedné z nich), tak na města + administrativně přidružené vesničky. [*] Zhruba proto, že problémem jsou samostatná sídla, která jsou pouze ZSJ, v takovém případě jsou obyvatelé těchto sídel započítáni dvakrát. A není tomu možné rozumně zabránit, protože ZSJ není hierarchicky podřízeno části obce. Petr Morávek aka Xificurk signature.asc Description: OpenPGP digital signature ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] UIR-ZSJ - části obce, základní sídelní jednotky
Dne 2.1.2012 16:53, Petr Morávek [Xificurk] napsal(a): hanoj napsal(a): *** postup je popsan vyse, funkce vztahu mezi rozlohou a poctem obyvatel sidla poskytnu na pozadani. O to bych určitě měl zájem. Ja se snazim vybrat nejjednoduseji ty casti UIR-ZSJ, ktere lze s vysokou uspesnosti importovat ve velkych kusech (rekneme okresech) a to COBE.DBF a OBCE.DBF. U ZSJ je zvysena mira selekce nutna, tudiz chapu potrebnost poloautomatickeho postupu. Máš pravdu, že tenhle přístup by měl umožnit importovat OBCE a COBE automaticky s přiměřeným počtem chyb. A potom můžem pokračovat s opravami a poloautomatickým doplněním ZSJ. Ad Alternativní systém tagů (Hanoj): Jestli jsem to dobře pochopil, tak se oba návrhy moc neliší... Já jsem to jen popisoval z pohledu mapera, ty z pohledu dat v UIR-ZSJ. Asi zbývá doladit pár věcí: 1) Jak už jsem psal, dataset MCAST (dělení statutárních měst) bych vynechal - jsou tam většinou jen očíslované městské části, a ty co nějaké rozumné jméno mají se dublují s COBE... protože dělení na městské části a části obce jsou zhruba na stejné úrovni. 2) suburb Původně jsem navrhoval takto označit všechny části obce uvnitř sídla city/town/village. Není mi přesně jasné, pro co navrhuješ ty - jen čtvrti ve statutárních městech? Nebo všechny části obce uvnitř sídla town/city (k tomu se teď přikláním já)? 3) isolated_dwelling by měla být samota - problém je, že jestli se jedná o samotu nejde vykoukat jen z počtu obyvatel, možná by to šlo z počtu domů, ale to bysme museli přibrat ještě nějaký další rejstřík ČSÚ. To by ti nepomohlo, jak poznas co je obytna budova a co budova hosporarska? Muzes mit nekde hajovnu, ktera ma nejaky nazev a je to presne to co je samotou mineno a muzes mit nekde uplne podobne statek s 20ti budovama, a jednou/dvema obytnyma budovama ... --- A ještě jednou věcí asi trochu rozdmýchám diskuzi - kam a jak doplnit tag population. Imho má smys údaj doplňovat jen na samostatná sídla (tj. city/town/village/hamlet). Ale mnohem důležitější je, jaký údaj - protože aby to k něčemu bylo musí to být porovnatelná čísla. Podobně jako není možné vzít všechny části obce a prohlásit je za place=suburb, není možné slepě vzít údaj o počtu obyvatel a plácnout ho na odpovídající node. Můj návrh je: 1) jedná-li se o část obce: obyvatelstvo z COBE. 2) jedná-li se pouze o základní sídelní jednotku: obyvatelstvo ze ZSJ. 3) jedná-li se o administrativní centrum obce: obyvatelstvo z OBCE - součet obyvatelstva částí obce z kroku 1. Kde sem doplnoval, pouzil sem toto http://www.czso.cz/csu/2010edicniplan.nsf/publ/1301-10- ted uz je tam novejsi http://www.czso.cz/csu/2011edicniplan.nsf/p/1301-11 Pouzil sem samozrejme Tab. 3 Počet obyvatel v obcích České republiky a doplnoval sem podle toho i identifikaci (na nody), takze by to melo jit automaticky aktualizovat (jsou tam doplneny tagy lau1/lau2). Casti obci to neobsahuje, stejne jako spoustu vesnic. Tehnle postup zajišťuje několik věcí: - Součet hodnot tagu population ze všech sídel na území obce bude zhruba[*] odpovídat celkovému počtu obyvatel v dané obci. - Jednotlivé hodnoty jsou porovnatelné a reprezentují to, co se od nich očekává - počet obyvatel daného sídla. - Funguje to jak na obce vzniklé složením několika vesniček (obec je většinou pojmenovaná po jedné z nich), tak na města + administrativně přidružené vesničky. [*] Zhruba proto, že problémem jsou samostatná sídla, která jsou pouze ZSJ, v takovém případě jsou obyvatelé těchto sídel započítáni dvakrát. A není tomu možné rozumně zabránit, protože ZSJ není hierarchicky podřízeno části obce. Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] UIR-ZSJ - části obce, základní sídelní jednotky
jzvc napsal(a): A ještě jednou věcí asi trochu rozdmýchám diskuzi - kam a jak doplnit tag population. Imho má smys údaj doplňovat jen na samostatná sídla (tj. city/town/village/hamlet). Ale mnohem důležitější je, jaký údaj - protože aby to k něčemu bylo musí to být porovnatelná čísla. Podobně jako není možné vzít všechny části obce a prohlásit je za place=suburb, není možné slepě vzít údaj o počtu obyvatel a plácnout ho na odpovídající node. Můj návrh je: 1) jedná-li se o část obce: obyvatelstvo z COBE. 2) jedná-li se pouze o základní sídelní jednotku: obyvatelstvo ze ZSJ. 3) jedná-li se o administrativní centrum obce: obyvatelstvo z OBCE - součet obyvatelstva částí obce z kroku 1. Kde sem doplnoval, pouzil sem toto http://www.czso.cz/csu/2010edicniplan.nsf/publ/1301-10- ted uz je tam novejsi http://www.czso.cz/csu/2011edicniplan.nsf/p/1301-11 Pouzil sem samozrejme Tab. 3 Počet obyvatel v obcích České republiky a doplnoval sem podle toho i identifikaci (na nody), takze by to melo jit automaticky aktualizovat (jsou tam doplneny tagy lau1/lau2). Casti obci to neobsahuje, stejne jako spoustu vesnic. To si právě myslím, že není úplně šťastné - ten jeden uzel nereprezentuje obec (ke které lze dohledat LAU2 a počet obyvatel), tu reprezentuje relace obce. S přimhouřením oka to lze tolerovat u větších měst, ale tím to končí... u venkovských obcí složených z více samostatných vesnic je to úplně neintuitivní. Jeden příklad za všechny - obec Rabštejnská Lhota (595 obyv.) je složená ze třech samostatných vesnic (které jsou taky jedinými třemi částmi obce) - Rabštejn (41), Rabštejnská Lhota (431), Smrkový Týnec (123). Tzn. na území obce (vymezeném relací s admin_level=8) sice žije 595 obyvatel, ale jen cca dvě třetiny z nich žije v sídle označeném nodem s place=village. Podobně dělených obcí je v republice kupa a v některých případech dokonce ani není vesnice, která nese jméno obce, tou největší. Petr Morávek aka Xificurk PS: Tím rozhodně nechci hanět práci tvoji a dalších lidí na doplňování údajů o počtu obyvatel! Je super, že tam už teď aspoň něco máme. Jen si myslím, že v případě hromadného doplnění sídel z UIR-ZSJ by to asi chtělo vymyslet něco chytřejšího. attachment: xificurk.vcf signature.asc Description: OpenPGP digital signature ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] UIR-ZSJ - části obce, základní sídelní jednotky
Dne 2.1.2012 23:22, Petr Morávek [Xificurk] napsal(a): jzvc napsal(a): A ještě jednou věcí asi trochu rozdmýchám diskuzi - kam a jak doplnit tag population. Imho má smys údaj doplňovat jen na samostatná sídla (tj. city/town/village/hamlet). Ale mnohem důležitější je, jaký údaj - protože aby to k něčemu bylo musí to být porovnatelná čísla. Podobně jako není možné vzít všechny části obce a prohlásit je za place=suburb, není možné slepě vzít údaj o počtu obyvatel a plácnout ho na odpovídající node. Můj návrh je: 1) jedná-li se o část obce: obyvatelstvo z COBE. 2) jedná-li se pouze o základní sídelní jednotku: obyvatelstvo ze ZSJ. 3) jedná-li se o administrativní centrum obce: obyvatelstvo z OBCE - součet obyvatelstva částí obce z kroku 1. Kde sem doplnoval, pouzil sem toto http://www.czso.cz/csu/2010edicniplan.nsf/publ/1301-10- ted uz je tam novejsi http://www.czso.cz/csu/2011edicniplan.nsf/p/1301-11 Pouzil sem samozrejme Tab. 3 Počet obyvatel v obcích České republiky a doplnoval sem podle toho i identifikaci (na nody), takze by to melo jit automaticky aktualizovat (jsou tam doplneny tagy lau1/lau2). Casti obci to neobsahuje, stejne jako spoustu vesnic. To si právě myslím, že není úplně šťastné - ten jeden uzel nereprezentuje obec (ke které lze dohledat LAU2 a počet obyvatel), tu reprezentuje relace obce. S přimhouřením oka to lze tolerovat u větších měst, ale tím to končí... u venkovských obcí složených z více samostatných vesnic je to úplně neintuitivní. Jeden příklad za všechny - obec Rabštejnská Lhota (595 obyv.) je složená ze třech samostatných vesnic (které jsou taky jedinými třemi částmi obce) - Rabštejn (41), Rabštejnská Lhota (431), Smrkový Týnec (123). Tzn. na území obce (vymezeném relací s admin_level=8) sice žije 595 obyvatel, ale jen cca dvě třetiny z nich žije v sídle označeném nodem s place=village. Podobně dělených obcí je v republice kupa a v některých případech dokonce ani není vesnice, která nese jméno obce, tou největší. Ono je to jeste ponekud horsi ... kdyz vemu nejmensi uzemni jednotku jakou mame v mape (relace) tak casto je v ni vice obci a ani jedna z nich nema v tom seznamu pocet obyvatel, neb je to zahrnuto pod nejakou vyssi (ne nutne vetsi) obec. Ale otazka je, jestli je nutne mit v mape presne udaje u kazde samoty. IMO pri poctech tisice se v tom nejaka viska ztrati a pri poctech stovky je to uz z hlediska mapovani (a pripadneho vyuziti pro reneder) stejna informace, jako ze tam neco je, co ma stejne smysl renederovat az pri maximalnich zoomech. Pokud to navic ma fungovat jako indikator tohle renederuj, paac to je ta obec na kterou vede znaceni/je to centrum oblasti/... tak jsou lepsi ty soucty na nodu obce. Ovsem pokud dobre vidim, tak mapnik na to kasle. Zoom 11 = bez vesnic. A byt na mape jsou vesnice vetsi nez nektera renederovana mesta, tak nazvy tam pri tomhle zoomu nemaji. Priklad - Hostomice (1266) vs Ledvice (566). Ledvice jsou jako town, Hostomice jako vilage (neresme ted, ze to je asi kravina). Petr Morávek aka Xificurk PS: Tím rozhodně nechci hanět práci tvoji a dalších lidí na doplňování údajů o počtu obyvatel! Je super, že tam už teď aspoň něco máme. Jen si myslím, že v případě hromadného doplnění sídel z UIR-ZSJ by to asi chtělo vymyslet něco chytřejšího. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] UIR-ZSJ - části obce, základní sídelní jednotky
*** postup je popsan vyse, funkce vztahu mezi rozlohou a poctem obyvatel sidla poskytnu na pozadani. O to bych určitě měl zájem. *** Postup ke vzorci je v souboru oo.org ODS. Dale je prilozeno pro kontrolu zastavene uzemi sidel CR nad 5 ha (cca nad 300-500 obyv) dle CORINE 2006. http://osm.templ.net/osm-uir-anal2.tar.gz Ad Alternativní systém tagů (Hanoj): Jestli jsem to dobře pochopil, tak se oba návrhy moc neliší... Já jsem to jen popisoval z pohledu mapera, ty z pohledu dat v UIR-ZSJ. *** Oba pristupy povazuji za dulezite. Urcite budou potrebne i pro mappery i uzivatele map/dat i obecnou informovanost o importu. 1) Jak už jsem psal, dataset MCAST (dělení statutárních měst) bych vynechal - jsou tam většinou jen očíslované městské části, a ty co nějaké rozumné jméno mají se dublují s COBE... protože dělení na městské části a části obce jsou zhruba na stejné úrovni. *** OK 2) suburb Původně jsem navrhoval takto označit všechny části obce uvnitř sídla city/town/village. Není mi přesně jasné, pro co navrhuješ ty - jen čtvrti ve statutárních městech? Nebo všechny části obce uvnitř sídla town/city (k tomu se teď přikláním já)? *** Na wiki se o suburb mluvi jako jednotce s vlastnim uradem (mestska cast/obvod), kdezto neighbourhood jako ctvrti. Ve vztahu k bodu 1) vyse to sice nebude uplne presne, ale cosi to mozna vypovida. 3) isolated_dwelling by měla být samota - problém je, že jestli se jedná o samotu nejde vykoukat jen z počtu obyvatel, možná by to šlo z počtu domů, ale to bysme museli přibrat ještě nějaký další rejstřík ČSÚ. *** ano je to zjednoduseni, o rejstriku ZSJ s objekty nevim --- A ještě jednou věcí asi trochu rozdmýchám diskuzi - kam a jak doplnit tag population. Imho má smys údaj doplňovat jen na samostatná sídla (tj. city/town/village/hamlet). Ale mnohem důležitější je, jaký údaj - protože aby to k něčemu bylo musí to být porovnatelná čísla. Podobně jako není možné vzít všechny části obce a prohlásit je za place=suburb, není možné slepě vzít údaj o počtu obyvatel a plácnout ho na odpovídající node. Můj návrh je: 1) jedná-li se o část obce: obyvatelstvo z COBE. 2) jedná-li se pouze o základní sídelní jednotku: obyvatelstvo ze ZSJ. 3) jedná-li se o administrativní centrum obce: obyvatelstvo z OBCE - součet obyvatelstva částí obce z kroku 1. *** OK. Ale nejak bych ocekaval (mozna naivne, protoze to nejde), ze na prvni pohled (nejen ze znalosti importu a pouziti admin_centre) poznam, o jaky pocet obyvatel jde dle bodu 1) až 3) [*] Zhruba proto, že problémem jsou samostatná sídla, která jsou pouze ZSJ, v takovém případě jsou obyvatelé těchto sídel započítáni dvakrát. A není tomu možné rozumně zabránit, protože ZSJ není hierarchicky podřízeno části obce. *** Podrizenost ZSJ COBE tu je skrze UTJ, ale na prvni pohled neni v UIR-ZSJ vyjadrena. Otazka je take na udrzitelnost a zbytnost takovych udaju v OSM. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] dessiner des limites administratives (réutilisation)
Le 30 décembre 2011 21:23, Vincent Pottier vpott...@gmail.com a écrit : Le 28/12/2011 17:24, Bruno Cortial a écrit : Salut, Attention ce qui suit est écrit par un newbi, qui se creuse toujours pour cerner les possibilités de rendus ! Un PLU cela fait beaucoup de polygones pour un rendu vecteur en ligne. Les exemples de rendu vecteur lourds que j'ai pu voir en ligne combinait tuilage et simplification. En gros pour chaque niveau de zone on découpe les données vecteur en tuile, et en fonction du niveau de zoom on simplifie plus ou moins la géométrie (sinon le navigateur explose). Cela fait beaucoup de traitements préalables sur les données et j'ai rien vu de clé en main. Comme l'a écrit Frédéric, le raster est préférable dans cette situation Si j'avais un fichier PLU au format SHP comme celui-là [1] ou les extractions des limites de commune d'OSM [2], j'essaierai Tilemill [3] pour générer de zolies tuiles raster semi-transparentes. Tilemill peut générer ces tuiles dans un unique fichier au format MBTiles (basé sur SQLite). Ce fichier MBT déposé sur un serveur web qui autorise le php (comme ceux de nos FAI) et un bout de code php pour servir les tuiles à OpenLayers et ça doit marcher! En fait ça marche [4]. A+ BrunoC [1] http://www.data.gouv.fr/**donnees/view/Zonages-des-PLU-**30383158http://www.data.gouv.fr/donnees/view/Zonages-des-PLU-30383158 [2] http://export.openstreetmap.**fr/contours-administratifs/** export-communes/http://export.openstreetmap.fr/contours-administratifs/export-communes/ [3] http://mapbox.com/tilemill/ [4] http://projects.bryanmcbride.**com/ol_mbtiles/http://projects.bryanmcbride.com/ol_mbtiles/ Excellent le newby ! Je teste immédiatement ! -- FrViPofm Bonjour, et Bonne Année Ouverte et bien Mappée ! Ok pour les rendus bitmaps. Mais j'aimerai bien avoir ces fameuses limites administratives en SVG pour pouvoir faire des cartes exploitables avec InkSpace pour de l'affichage web ou du print. Des cartes comme celles sur wikipedia ou http://libertic.wordpress.com/2012/01/02/carte-de-france-de-lopen-data-v4/ -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] dessiner des limites administratives (réutilisation)
Tilemill permet de faire des tuiles comme expliqué précédemment par Bruno dans le fil de discussion. Mais générer de belles images en SVG c'est possible également Le 2 janvier 2012 12:19, Cyrille Giquello cyrill...@gmail.com a écrit : Le 30 décembre 2011 21:23, Vincent Pottier vpott...@gmail.com a écrit : Le 28/12/2011 17:24, Bruno Cortial a écrit : Salut, Attention ce qui suit est écrit par un newbi, qui se creuse toujours pour cerner les possibilités de rendus ! Un PLU cela fait beaucoup de polygones pour un rendu vecteur en ligne. Les exemples de rendu vecteur lourds que j'ai pu voir en ligne combinait tuilage et simplification. En gros pour chaque niveau de zone on découpe les données vecteur en tuile, et en fonction du niveau de zoom on simplifie plus ou moins la géométrie (sinon le navigateur explose). Cela fait beaucoup de traitements préalables sur les données et j'ai rien vu de clé en main. Comme l'a écrit Frédéric, le raster est préférable dans cette situation Si j'avais un fichier PLU au format SHP comme celui-là [1] ou les extractions des limites de commune d'OSM [2], j'essaierai Tilemill [3] pour générer de zolies tuiles raster semi-transparentes. Tilemill peut générer ces tuiles dans un unique fichier au format MBTiles (basé sur SQLite). Ce fichier MBT déposé sur un serveur web qui autorise le php (comme ceux de nos FAI) et un bout de code php pour servir les tuiles à OpenLayers et ça doit marcher! En fait ça marche [4]. A+ BrunoC [1] http://www.data.gouv.fr/**donnees/view/Zonages-des-PLU-**30383158http://www.data.gouv.fr/donnees/view/Zonages-des-PLU-30383158 [2] http://export.openstreetmap.**fr/contours-administratifs/** export-communes/http://export.openstreetmap.fr/contours-administratifs/export-communes/ [3] http://mapbox.com/tilemill/ [4] http://projects.bryanmcbride.**com/ol_mbtiles/http://projects.bryanmcbride.com/ol_mbtiles/ Excellent le newby ! Je teste immédiatement ! -- FrViPofm Bonjour, et Bonne Année Ouverte et bien Mappée ! Ok pour les rendus bitmaps. Mais j'aimerai bien avoir ces fameuses limites administratives en SVG pour pouvoir faire des cartes exploitables avec InkSpace pour de l'affichage web ou du print. Des cartes comme celles sur wikipedia ou http://libertic.wordpress.com/2012/01/02/carte-de-france-de-lopen-data-v4/ -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] dessiner des limites administratives (réutilisation)
2012/1/2 Ab_fab gamma@gmail.com: Tilemill permet de faire des tuiles comme expliqué précédemment par Bruno dans le fil de discussion. Mais générer de belles images en SVG c'est possible également Sinon, pour faire du SVG, il y a aussi le bon vieux osmarender: http://wiki.openstreetmap.org/wiki/Osmarender Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Article sur OSM sur le portail de services aux citoyens sur telephone mobile
Un article assez sympa : http://www.proximamobile.fr/article/la-montee-en-puissance-des-cartes-openstreetmap-sur-mobiles Et le site est lie a 2 ministeres ( cf le logo en haut a droite et les mentions legales ) Julien PS : meilleurs voeux pour 2012 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Une annee d edition 2011
Toujours sympa ces videos: http://geotribu.net/node/485 Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Contours administratifs français : fin des limites au 1/100.000e
Bonsoir, Suite à l'appel lancé fin septembre par Sly ([1]) pour l'utilisation des limites administratives supérieures au niveau 8 (départements et régions), un grand nettoyage des limites importées depuis la source litigieuse et approximative (échelle 1/100.000e) Cartographes Associés a été entrepris. Ces limites ont été remplacées par celles provenant du cadastre, seule source légale pour définir ces limites, généralement de plans images à l'échelle 1/2500 ou 1/5000e (et pour certaines communes trop difficile à géoréférencer, des tableaux d'assemblages). Au départ, 182 ways provenaient encore de cette source litigieuse. Le 10 décembre, ce nombre était tombé à 16. A cette date, les limites restantes ont été remplacées par celles provenant de la base GEOFLA de l'IGN, des données tout juste libérées dans une license compatible avec celles d'OSM ([2]), remontant par la même à 19 ways. Mais ces limites restaient approximatives puisque extrêment simplifiées pour un usage au 1/100.000e. Aujourd'hui, ces 19 derniers ways ont eux aussi tous été remplacés par des limites issues du cadastre. Cela nous permet maintenant d'offrir des limites départementales à une échelle cohérente et de grande qualité. Un grand merci à tous ceux qui ont contribué à cette tâche de grande ampleur et souvent ingrate, les limites ajoutées étant toutes issues de plans images cadastraux à géoréférencer manuellement. Pieren [1] http://lists.openstreetmap.org/pipermail/talk-fr/2011-September/035892.html [2] http://lists.openstreetmap.org/pipermail/talk-fr/2011-December/038609.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Contours administratifs français : fin des limites au 1/100.000e
De : Pieren pier...@gmail.com Bonsoir, Suite à l'appel lancé fin septembre par Sly ([1]) pour l'utilisation des limites administratives supérieures au niveau 8 (départements et régions), un grand nettoyage des limites importées depuis la source litigieuse et approximative (échelle 1/100.000e) Cartographes Associés a été entrepris. Ces limites ont été remplacées par celles provenant du cadastre, seule source légale pour définir ces limites, généralement de plans images à l'échelle 1/2500 ou 1/5000e (et pour certaines communes trop difficile à géoréférencer, des tableaux d'assemblages). Au départ, 182 ways provenaient encore de cette source litigieuse. Le 10 décembre, ce nombre était tombé à 16. A cette date, les limites restantes ont été remplacées par celles provenant de la base GEOFLA de l'IGN, des données tout juste libérées dans une license compatible avec celles d'OSM ([2]), remontant par la même à 19 ways. Mais ces limites restaient approximatives puisque extrêment simplifiées pour un usage au 1/100.000e. Aujourd'hui, ces 19 derniers ways ont eux aussi tous été remplacés par des limites issues du cadastre. Cela nous permet maintenant d'offrir des limites départementales à une échelle cohérente et de grande qualité. Un grand merci à tous ceux qui ont contribué à cette tâche de grande ampleur et souvent ingrate, les limites ajoutées étant toutes issues de plans images cadastraux à géoréférencer manuellement. Magnifique boulot, merci les fourmis !! Julien De : Pieren pier...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Lundi 2 Janvier 2012 22h20 Objet : [OSM-talk-fr] Contours administratifs français : fin des limites au 1/100.000e Bonsoir, Suite à l'appel lancé fin septembre par Sly ([1]) pour l'utilisation des limites administratives supérieures au niveau 8 (départements et régions), un grand nettoyage des limites importées depuis la source litigieuse et approximative (échelle 1/100.000e) Cartographes Associés a été entrepris. Ces limites ont été remplacées par celles provenant du cadastre, seule source légale pour définir ces limites, généralement de plans images à l'échelle 1/2500 ou 1/5000e (et pour certaines communes trop difficile à géoréférencer, des tableaux d'assemblages). Au départ, 182 ways provenaient encore de cette source litigieuse. Le 10 décembre, ce nombre était tombé à 16. A cette date, les limites restantes ont été remplacées par celles provenant de la base GEOFLA de l'IGN, des données tout juste libérées dans une license compatible avec celles d'OSM ([2]), remontant par la même à 19 ways. Mais ces limites restaient approximatives puisque extrêment simplifiées pour un usage au 1/100.000e. Aujourd'hui, ces 19 derniers ways ont eux aussi tous été remplacés par des limites issues du cadastre. Cela nous permet maintenant d'offrir des limites départementales à une échelle cohérente et de grande qualité. Un grand merci à tous ceux qui ont contribué à cette tâche de grande ampleur et souvent ingrate, les limites ajoutées étant toutes issues de plans images cadastraux à géoréférencer manuellement. Pieren [1] http://lists.openstreetmap.org/pipermail/talk-fr/2011-September/035892.html [2] http://lists.openstreetmap.org/pipermail/talk-fr/2011-December/038609.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] 'Wikipedia of Maps' Challenges Google
Un article parlant de certains services qui migrent de Google Maps vers OSM suite aux nouvelles conditions d utilisation des API google. http://www.technologyreview.com/blog/mimssbits/27443/___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Contours administratifs français : fin des limites au 1/1.000.000e
\o/ Une année qui commence bien :-) Le 02/01/2012 22:35, THEVENON Julien a écrit : * De :* Pieren pier...@gmail.com * *Bonsoir, * *Suite à l'appel lancé fin septembre par Sly ([1]) pour l'utilisation * *des limites administratives supérieures au niveau 8 (départements et * *régions), un grand nettoyage des limites importées depuis la source * *litigieuse et approximative (échelle 1/100.000e) Cartographes * *Associés a été entrepris. Ces limites ont été remplacées par celles * *provenant du cadastre, seule source légale pour définir ces limites, * *généralement de plans images à l'échelle 1/2500 ou 1/5000e (et pour * *certaines communes trop difficile à géoréférencer, des tableaux * *d'assemblages). * *Au départ, 182 ways provenaient encore de cette source litigieuse. Le * *10 décembre, ce nombre était tombé à 16. A cette date, les limites * *restantes ont été remplacées par celles provenant de la base GEOFLA de * *l'IGN, des données tout juste libérées dans une license compatible * *avec celles d'OSM ([2]), remontant par la même à 19 ways. Mais ces * *limites restaient approximatives puisque extrêment simplifiées pour un * *usage au 1/100.000e. * *Aujourd'hui, ces 19 derniers ways ont eux aussi tous été remplacés par * *des limites issues du cadastre. * *Cela nous permet maintenant d'offrir des limites départementales à une * *échelle cohérente et de grande qualité. Un grand merci à tous ceux qui * *ont contribué à cette tâche de grande ampleur et souvent ingrate, les * *limites ajoutées étant toutes issues de plans images cadastraux à * *géoréférencer manuellement. Magnifique boulot, merci les fourmis !! Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] forum: Traces Renault Carminat Tomtom
peut-être un début de réponse sur http://forum.hardware.fr/hfr/gsmgpspda/GPS/restituer-trace-google-sujet_17738_1.htm Apparemment, cela nécessiterait un petit outil en plus sur le tomtom ? - On ne va jamais aussi loin que lorsque l'on ne sait pas où l'on va... www.partir-en-vtt.com -- View this message in context: http://gis.638310.n2.nabble.com/forum-Traces-Renault-Carminat-Tomtom-tp7142099p7145929.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] forum: Traces Renault Carminat Tomtom
On 01/01/12 16:21, fo...@letuffe.org wrote: Bonjour, Comment enregistrer les traces sur un GPS Renault Carminat Tomtom, afin d'ajouter des routes dans OSM ? Je vous remercie. Bonjour, La page http://wiki.openstreetmap.org/wiki/TomTom donne plusieurs solutions pour les TomTom. Je ne sais pas si elles sont compatibles avec les Carminat. Si vous faites des essais, faites part de vos résultats ici. (Note : j'avais posté cette réponse sur le forum, pensant qu'elle serait aussi renvoyée vers la ML, mais non ? ) Jean-Claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] お正月マッピングパーティー開催！
ikiyaです。 神楽坂マッピングパーティー無事終了しました。 参加された皆様、お疲れ様でした。 お天気も問題なく、参加者５名で新春の神楽坂を てくてく散策できました。 ２グループに別れてのロギング１時間、その後合流して 食事、お茶しながらログ確認OSM説明に２時間半程度の スケジュールでした。 神楽坂の起伏に富んだ地形と多くの史跡を 体感、見学しながらのマッピングになりました。 地物の捉え方やタグ付けについて現地で説明する といった体験マッピング的な内容となりました。 お疲れ様でした。 --- On Sun, 2012/1/1, ikiya insidekiwi...@yahoo.co.jp wrote: ikiyaです。 明日の参加予定者は現在7名です。 １１時前には飯田橋駅西口にいます。 （午前中は北の丸と九段下周辺、ロギングしています。） 神楽坂マッピングパーティーwikiページはこちらになります。 http://wiki.openstreetmap.org/wiki/JA:Kagurazaka_mapping_party_20120102 明日は宜しくお願いいたします。楽しみましょう。 --- On Sat, 2011/12/31, ikiya insidekiwi...@yahoo.co.jp wrote: ikiyaです。 参加表明ありがとうございます。 よろしくお願いしまします。 飯田橋駅西口にOSMマークの付いたバック背負って GPSぶらさげて立っています。 --- On Sat, 2011/12/31, 木下 兼一 kin...@tke.att.ne.jp wrote: 木下と申します。 お正月マッピングパーティ、参加希望です。 GPSについては、GPSレシーバー付きAdvanced W-ZERO3を持っていく予定ですよろしくお願いいたします。 On 2011/12/29, at 9:56, ikiya wrote: ikiyaです。 恒例？お正月マッピングパーティーを都内で開催できればと思います。 ・都合もあって場所は、神楽坂周辺を考えています。 ・マッピング手法は問いません。 ・マッピングのターゲットは各自にお任せします。（飲食店POI、バス停、交差点名、道路一方通行、ビル階数etc） ・初心者歓迎、GPSなくても参加OKです。（参加表明の際にGPSの有無お知らせください。） ・1〜2時間外でロギングしてあとは食事、お茶しながらワイワイOSM教室、OSM座談会できればと思います。 ・詳細は人数次第でつめていきたいと思います。 『2012新春！神楽坂界隈OSMマッピング』 2012年1月2日（月） 飯田橋駅西口改札前午前11時集合、午後3時頃解散予定 お正月ご都合よろしい方い ら っしゃいましたら 参加表明お願いします。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja 木下 兼一e-mail: kin...@tke.att.ne.jp ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] 駐車場マップ(Fwd: [OSM-talk] New version of the parking map)
東です。 駐車場マップで日本もレンダリング対象になっています。 http://parking.openstreetmap.de/?zoom=17lat=35.7848lon=139.90086layers=B000TT Wikiを参考にタグ付けするといろいろレンダリングされるようです。 http://wiki.openstreetmap.org/wiki/JA:Tag:amenity%3Dparking http://wiki.openstreetmap.org/wiki/Proposed_features/parking:lane ＜例＞ 紫：無料駐車場（デフォルト） 濃い水色：有料駐車所場（fee=yesタグあり） 茶色：お客様用駐車場 まだ少ししか試していないのですが、 モノトーンのmapnik上での表現は分かりやすく 駐車場をちゃんとマッピングしてみようかという気にさせてくれます。 尚、レンダリングの反映には時間が掛かるようです。 また、中間ズームレベルのタイルなど、一部スムーズに表現されないものもあります。 -- Forwarded message -- From: Kay Drangmeister k...@drangmeister.net Date: Mon, 02 Jan 2012 17:26:01 +0100 Subject: [OSM-talk] New version of the parking map To: t...@openstreetmap.org t...@openstreetmap.org Hi all, Happy new year! I updated the parking map style on http://parking.openstreetmap.de Changes are: * new keywords are now accepted for parking:lane:* * parallel instead of inline * perpendicular instead of orthogonal * the old keywords are supported for a while, but discouraged * vending machines for parking tickets are now displayed * Parking lots for shops have now the shop names (parking:condition:area:customers=xxx) * Parking nodes are now displayed with the correct color (i.e. green for free, etc.) * Parking areas are now semi-transparent, so that the parking_aisles are seen through * incomplete data (i.e. unknown parking condition) is displayed in purple) Please debug your area (use /dirty to redraw tiles) and comment on any bugs/wishes. Also, try to add additional tags for purple parking lots (best: parking:condition:area= free/ticket/customers/private/disc, at least: fee=yes/no) Kind regards, Kay ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] JOSMの翻訳で分からない所
12/01/02 ribbon o...@ns.ribbon.or.jp: 現時点で75%なので少しだけ追加しました、が、 Lit どう訳しましょう? 「照明」でいかがでしょう。 apartment アパート、マンション としてみました。 hut (ほったて)小屋 としてみました。 ほかにもレビュー希望なものはいくつかありますので、 チェックしてみてください。おおる oota ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
[Talk-GB] Changeset Reversal: ok, who broke Scotland?
Looking at the map around Inverness and in the Orkney Islandsit looks like the coastline's been broken: Inverness and Kirkwall are both flooded according to the map. This seems unlikely, even for rainy old Scotland. I don't have the nous to fix this one myself I'm afraid, and I think it's been that way for a while -- still struggling to find the changeset. cheers ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Changeset Reversal: ok, who broke Scotland?
Jack, Yes, it has been like this for about 2-3 weeks now, but I think it is fixed (sort of). It has stopped flooding new tiles, and it only affects the mapnik rendering now. I am pretty sure the osma renderer was affected, but then dried out once the coastline was sorted. I think it may be to do with how mapnik only recalculates coastlines periodically (but don't quote me on this). I looked previously and wasn't able to find a change set that broke things (around Inverness), but did find one around Ardisier that was correcting problems. I have just searched OWL, and these 2 might be related to the issue - but I'm not sure at all. http://www.openstreetmap.org/browse/changeset/10063288 http://www.openstreetmap.org/browse/changeset/10112311 Cheers, Donald -- Donald Noble http://drnoble.co.uk - http://flickr.com/photos/drnoble ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
[Talk-us] Imports information on the wiki
Hi, There's a lot of imports / fixbots / scripts that have affected the US data over the years. I am finding this out slowly by slowly, asking questions here and on IRC sometimes. The Road Name Expansion script is a recent example that was discussed on the tagging list and here. Another is that there are actually two different GNIS imports. This makes it hard for mappers to focus their efforts when they first start out. Also (and as importantly), external data consumers will have a really hard time processing and using OSM data if information on imports and fixbots is not consolidated - especially if a fixbot was only run on half the country, as was the case with the name expansion. I propose a wiki editing effort to consolidate information on scripts and fixbots run in the US. I know that there is a global Import Catalog page already, and this would partially duplicate the information found there. I think it makes sense to do it anyway because: * The US is a specific and important market for many potential data consumers, and they need this info in one place * The US data is particularly strongly shaped by imports and automated edits. I have made a start here: http://wiki.openstreetmap.org/wiki/WikiProject_United_States/Imports_And_Automated_Edits This page would replace or be integrated into the current Data page http://wiki.openstreetmap.org/wiki/WikiProject_United_States/Data - I did not want to overhaul that page just yet without engaging in this discussion first. So: * US imports and fixbots page: good idea? * Format of the page: good? Maybe a table format? Include more information? If so, which? * Please add / complete / modify and most importantly discuss! -- martijn van exel geospatial omnivore 1109 1st ave #2 salt lake city, ut 84103 801-550-5815 http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Imports information on the wiki
Am 02.01.2012 20:05, schrieb Martijn van Exel: Hi, There's a lot of imports / fixbots / scripts that have affected the US data over the years. I am finding this out slowly by slowly, asking questions here and on IRC sometimes. The Road Name Expansion script is a recent example that was discussed on the tagging list and here. Another is that there are actually two different GNIS imports. This makes it hard for mappers to focus their efforts when they first start out. Also (and as importantly), external data consumers will have a really hard time processing and using OSM data if information on imports and fixbots is not consolidated - especially if a fixbot was only run on half the country, as was the case with the name expansion. I propose a wiki editing effort to consolidate information on scripts and fixbots run in the US. I know that there is a global Import Catalog page already, and this would partially duplicate the information found there. I think it makes sense to do it anyway because: * The US is a specific and important market for many potential data consumers, and they need this info in one place * The US data is particularly strongly shaped by imports and automated edits. I have made a start here: http://wiki.openstreetmap.org/wiki/WikiProject_United_States/Imports_And_Automated_Edits This page would replace or be integrated into the current Data page http://wiki.openstreetmap.org/wiki/WikiProject_United_States/Data - I did not want to overhaul that page just yet without engaging in this discussion first. So: * US imports and fixbots page: good idea? * Format of the page: good? Maybe a table format? Include more information? If so, which? * Please add / complete / modify and most importantly discuss! Hi Martijn, thanks for setting this up. Personaly I would recommend to use the Imports mainpage, as so everybody else can find them. Even /subpages isn't that wise (but I was a fan of it, too ;)) as it makes it very hard to place links and tries to build up hirachies. But a wiki is a ontology and therefore works with categories :) bye Matthias (user:!i!) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Imports information on the wiki
2012/1/2 Matthias Meißer dig...@arcor.de: Am 02.01.2012 20:05, schrieb Martijn van Exel: [...] Hi Martijn, thanks for setting this up. Personaly I would recommend to use the Imports mainpage, as so everybody else can find them. Even /subpages isn't that wise (but I was a fan of it, too ;)) as it makes it very hard to place links and tries to build up hirachies. But a wiki is a ontology and therefore works with categories :) The reason for doing it on a separate page is that it becomes more manageable. The imports page is huge and can be hard to both edit and consume for that reason. By categories, do you mean similar to the 'Users in ...' categories? That would make sense to me, but would not require to maintain the Imports page. We could then tag each import description page with categories [Import] [Country] or [Fixbot] [Country]. I don't know if mediawiki knows about administrative boundary hierarchies - if so you could have [Import] [San_Diego] or similar and still have the import show up in the auto-generated list of 'Imports in the US'. I like this approach in general, but just having an auto-generated list of imports and fixbots without any context is not enough. The page would need to provide some context, especially for those external to OSM seeking information. I don't know if / how that could be achieved? -- martijn van exel geospatial omnivore 1109 1st ave #2 salt lake city, ut 84103 801-550-5815 http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Imports information on the wiki
Continued from tagging... On 1/2/2012 11:40 AM, Martijn van Exel wrote: What makes you think that the current common opinion is against automatic expansion? Mostly because of customary resistance to automatic imports, which is rooted in bad imports. Josh has noted in Tagging that it could give a false impression of quality to others - I don't agree because I've never considered an expanded name a measure of quality or synonymous with the removal of the tiger:reviewed=no flag. What in particular were the complaints made against the fixbot? Some of it was by finding the few obscure cases that don't yield to automation: The city of St Louis has several cases of St Louis Street Saint Louis Street style duplication. The streets are physically not connected and you must use the correct naming convention to go to the right place. Also - St Park Rd; is this Saint Park Road or State Park Road? Can/should the fixbot be improved to take them into account? I believe we could let it run if everyone agrees on the safe expansions. * Rd -* Road for example. And despite it being a bot, the author put in some significant block of time to review each upload for correctness and marked many errors that were clearly rooted in TIGER data. There is some minor discrepancy between TIGER abbreviations and common street sign / official USPS abbreviations also: Pky - Pkwy = Parkway especially if a fixbot was only run on half the country, as was the case with the name expansion. Ironically, having a split country situation forces data consumers to handle both the abbreviated and expanded case (Mainly Nominatum today). Even if the entire US data is expanded, that situation will continue to exist as new mappers arrive and have never dealt with anything but abbreviations on maps, street signs, or addresses. They may even re-abbreviate expanded names. Otherwise, we would need bots to run behind them and clean up new contributions to make them usable. Or waste other mapper's time to do it manually. But manually entered road names cannot be automatically expanded, since those will very seldom if ever have directional hints like TIGER data has. Nominatum should still continue to handle both cases. Although it has been said that map renderering is the place to abbreviate the full name, no map renderer currently does this as far as I know. If there is ever a custom US style OSM renderer, that would be a logical feature. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Imports information on the wiki
Hi, On 01/03/2012 12:01 AM, Mike N wrote: Mostly because of customary resistance to automatic imports, which is rooted in bad imports. I think that even imports that are well executed *technically* are usually bad because they worsen the ratio of mapper hours available to maintain data to amount of data requiring maintenance. Imports should only be allowed if there is a realistic expecation that the presence of the imported data will lead to a growth in our community of about the number of people that would have been required to survey the imported data in the first place. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Imports information on the wiki
On Mon, Jan 2, 2012 at 6:22 PM, Frederik Ramm frede...@remote.org wrote: I think that even imports that are well executed *technically* are usually bad because they worsen the ratio of mapper hours available to maintain data to amount of data requiring maintenance. Imports should only be allowed if there is a realistic expecation that the presence of the imported data will lead to a growth in our community of about the number of people that would have been required to survey the imported data in the first place. I think in this case, Martijn is reacting to the sheer number of half completed imports and fixbots in the US that have left areas half completed or half-right. It would be easy to say Manually fix the data, but I can tell you from experience that going around and manually fixing Rd to Road is not fun, and can, with the TIGER imports, be done safely (by looking at other tags and being careful with the expansion regex). This has been done for part of the country, but not the other part. Similarly, here in the mid-Atlantic region, we have several imports which have been both not-complete and done twice. I've spent many hours manually examining two polygons of the same geometry (some which share the same nodes, others which do not) only to remove one. Having users do these kind of operations adds nothing but busywork, and is error prone (in the second case, I've removed both sets of polygons by accident, for example). I think Martijn's focus on cleaning up the imports, especially in the US, should be welcome and encouraged. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
