Maps-l September 2009

maps-l@lists.wikimedia.org

16 participants
10 discussions

OSM-Wikimedia collaboration : what next ?
by hugo lopes 27 Sep '09

27 Sep '09

Hello everyone, Some questions about the OSMap-Wikimedia collaboration ; *Where is the active place ?* - the meta:OpenStreetMap<http://meta.wikimedia.org/wiki/OpenStreetMap#OpenStreetMap_and_Wikipedia>seems inactive, so... - where is the active place/page where OSMap-Wikimedia collaboration is working ? *Strategy.wikimedia.org initiative take the lead ?:* The Strategy wiki is becoming more active, and have a nice forms to fill for technology requests. I added a request of OSMap-Wikimedia collaboration to create an " Encyclopedic OpenStreetMap<http://strategy.wikimedia.org/wiki/Proposal:Encyclopedic_OpenStreetMap>". You can also copy the Encyclopedic OpenStreetMap request page, to create an other Graphics/OSM relate request<http://strategy.wikimedia.org/wiki/Call_for_proposals#Graphics>. By the way, maybe the (inactive?) meta:OpenStreetMap page may be move to this strategy wiki ? Do you agree ? *Currently on Wikimedia and Commons:* We are currently, on wikipedia, working in a really archaic way to create and manage maps. We work in JPG, PNG, SVG, file by file, duplicating images. Our countries lay out is netheir reliable, neither updatable. Google moved to a Web 2.0 way of mapmaking, OSM too. OSM open today to the wikimedia an efficient, and soon or later NEED web 2.0 way to manage maps (and eventually scheme drawing as well). *Reuse more OSM technologies for wiki maps...* In addition of the currently planned OSM "Road maps" integration, several other innovating technologies from the *Web 2.0 SVG OSM project* may actually be reuse for* encyclopedic purposes*. I here think mainly about : Collaborative map creation-improvement and multilanguage labelling by wikipedians ; expansion of OSM to the 7 major Wiki Map Style (w:WikiProject Maps/Conventions<http://en.wikipedia.org/wiki/en:Wikipedia:WikiProject_Maps/Conventions>; StyleEditor ); GIS topographic maps ; specific linguistic layers (thus avoiding drawing duplicata, easing drawing update, easing internationalisation/translations). *...and encyclopedic schemes:* But OSM also open the path for web 2.0 technical schemes drawing, SVG and online editing allowing, again, to create linguistic label layers (English labels layer ; German labels layer ; ...) without duplicating the subject's drawing (and possible mistakes), thus easing update and corrections. *Your opinions :* I will soon fill several such proposals on the Strategy wiki for those possible paths, but I would be happy to received your feedbacks : 1. your global opinions on thoses paths, 2. your opinion on the* feasability* of this ideas in the next years (delay) : _ OSM integration to wikipedia ? _ OSM expansion to 7 major wiki styles ? (with wiki icons, edit by wikipedians) _ OSM getting a function "create SVG scheme online" (collaborative tool) ? 3. is the Greenspun money still available and is it possible to link it to OSM collaboration project to expand its objectives ? 4. other proposal ? *Obstacles:* This will, for sure, need programmers working hard, in collaboration with OSM ones, to expand the set of tools available, or to adapt OSM to wikipedia/wikimedia encyclopedic graphic needs. Considering the huge task, a strong top-to-bottom leardership is need, and when considering the expertise need (programing, SVG-XML knowledge), founding may equally be need to achieve such view. *Founding ?* The now virtually death Greenspun project have about 20.000 US$ which HAVE TO BE USE to *"Improve illustration on wikimedia projects on the vectorial SVG side"* may maybe help such OSMap-Wikimedia collaboration. Does anyone tryed this way ? Is this money still available ? any information ? *End:* I launch here several innovating graphic-relate ideas. I sincerely think are them to be both *need* -to increase our graphic reliability and identity- and technically *feasible*. My own opinion is that, anyway, we [wikimedia] will have to move to those*web 2.0 graphic technologies sooner or later *, in the next few years. Since we can start the move toward those technologies now, since *our job* as 'experts' is to make advised choices to save human work force in order to do more (research of efficiency) : let's start now to walk on this path of encyclopedic graphism 2.0 : encyclopedic, collaborative, SVG (scalable), easily maintainable and translatable. Hoping your answers, Regards, -- 羅禹國 - Hugo LOPEZ (French), User:Yug (wikigraphist) Tw. tel: 09-8343-9890 Institute of Innovation, Technology and Management (Master 1) NCHU, Taizhong, Taiwan.

5 4

OSM-Wikimedia collaboration : what next ? (2nd) - need an official road map.
by hugo lopes 27 Sep '09

27 Sep '09

Hello, My apologies for this 2nd long email ;*] Web 1.0 (Commons-like) VS web 2.0 (OSM-like) :* Ok, so we agree : commons file-by-file map making is archaic and not long term sustainable, compare to more flexible, cuztomisable (skin), and evolutive OSM-like approaches. ok, we agree to affirm that current map creation on Wikimedia is not very effective. First, OSM, as well as Google map [you can create your maps] are the evidences that web 2.0 map creation does work on the user side. *Basic SVG Map concepts:* When we look at how is made a map, we see that it is done *layer after layer*. In SVG, each layer may be *display, or hidden*. This two points are very important for collaborative and *encyclopedic uses*. An OSM-like system may also output specific PNG/JPG/SVG files for download. *Soon to come, OSM Roads map integration :* OSM maps integration will provide us (very soon) : * Layers: 1. Land layer ; 2. Water layer ; 3. Administrative borders layer ; 4. Roads layer ; 5. icons layer ; 6. Labels layer. * View tool: specify the view/frame using geographic coordonies and zoom level ; * Skins: change the icon set, the color set, and all article's maps will by instantly update ; It's what you can see on http://u.nix.is/wiki/index.php/Maptest . It's the very-soon-to-come step, focus on Road maps. *Encyclopedic needs are wider : * It is important to remember: OSM is a project for GPS users, it thus focus on roads. Their web 2.0 map creation process allowed them to achieve great success. But we are not OSM. We are *Wikimedia*. We have not to focus on roads. We have us to manage a wider 'knowledge project', mainly Wikipedia, where maps have a key importance. An encyclopedia actually need mainly : Background layers (Lands, waters, borders, provided by OSM) • Road layers (p. by OSM) • Topographic layer (GIS data, zoomable) • Location maps (the country or district in grey, to put city dots upon it) • Locator maps (the country in 'red' within is context and the world) • Historical layers. *Technical needs for Wikimedia maps management :* Second, technically, on maps and knowledge management the need of : > 1. *reliability (bg): *more reliable land background ; > 2. *updatability:* easier maintenance (conventions, icon set updates, > colors updates) ; > 3. *reliability (2):* avoid information duplicata and ease information > correction ; > 4. *internationalization:* easier translations (without duplicating the > background), > make the move to 2.0 maps NEED. As the pro Google and OSM already did, the Wikimedia foundation will also have to make this move. *Thus, what next: own to process ?* Since the OSM approach is SVG based, so it is also possible to : ** Hide*: hide layers, by example roads and names, to get just administrative division : that's the "Wikipedia Location maps" ; * *Translate:* duplicate the label layer "English", translate the duplicata into Chinese, and hide (or keep) the former "English" layer, this without changing or duplicating other layers. This will ease wikipedia highly need internationalization. * *Add GIS data:* add GIS datas and style it : that's the highly appreciated "Wikipedia Topographic maps" ; * *Add specific layers:* use the background provide by OSM (Land, Water, Administrative borders), and let create upon it objects such "Italia path red" : that create the "Wikipedia Locator maps" (a country in red within its context: Europe, World) ; draw a path with the shape of Gaza in 1948, add some city names, use the provided icons: that's an "Wiki historical map". Those style of maps (Topographic, Location, Locator, Historical) are thousands on wikipedia, specific to wikipedia, and highly appreciate. I state it again : current web 1.0 Commons-like management & ducaplication-for-translations make our maps increasingly *unreliable*, while file-by-file management make map conventions impossible to implement. *Possible sytems to produce OSM-like Encyclopedic maps and fit wikimedia needs :* As previously said, layers can be display (+) or hidden (-). Thus, layers may be combine such : Location map Gaza : Zoom on Gaza [OSM Gaza - Roads - icons)] Locator map Gaza : Zoom on Middle-East [OSM Gaza - Roads - icons + Gaz in Red] Topographic map Gaza : Zoom on Gaza [OSM Gaza - Roads - icons] + topographic data Historical map Gaza 1948 : Zoom on Gaza [OSM Gaza - Roads - icons + Gaz1948_SVG_group (including Gaza1948 in yellow + icons + labels ...)] Historical map Gaza 1948-zh : Zoom on Gaza [OSM Gaza - Roads - icons + Gaz1948_SVG_group (including Gaza1948 in yellow + icons + labels...) - English labels + Chinese Labels] etc. Such formule/syntaxe may be save in the expanded OSM system under a shorter name : Historical_map_Gaza_1948-zh , associated with academic sources, and OSM license. Thus, within the article, we would have to add something such : [[Map:Historical map Gaza 1948-zh|300px|right|thumb|Gaza in 1948.]] Do you see the whole system ? Pretty similar of http://u.nix.is/wiki/index.php/Maptest , but fitting wikimedia wider encyclopedic needs: location, locator, topographic, historical. *Conclusion : Wikimedia encyclopedic needs, need specific expanded OSM system* OSM based approach allow: * Layer flexibility: hidding layers, adding layers ; * Style flexibility: install skin & icon set change ; instant style & icon update ; * Reliability: critical data layers (lands shape, topography) may stay lock ; * Collaboration and translations: letting users to work on specific layers (roads, labels, historic) and using provided locked backgrounds ; Adding to this, we know : * Specific needs : Wikimedia have specific, wider, encyclopedic knowledge needs. Thus, Wikimedia should *expand* OSM to fit *its* encyclopedic needs ; * Know needs: after 8 years of Wikipedia and 4 of Map Workshops (Graphic Labs), we know that Encyclopedia's users mainly request about 6-7 styles of map to display semantic knowledge. This will allow wikimedia to increase the *reliability* of its maps, and ease the creation of a graphic identity. *Integrate OSM, then Expand OSM : need of AN OFFICIAL ROAD MAP.* I'm not programmer. I thus just see to path to walk, and want to clearly set some objectives. My proposal is the following planning. 1. Integrate OSM to Wikipedia (see http://u.nix.is/wiki/index.php/Maptest ) : this is already and great step and soon to come ; 2. then: *Expand OSM* to get specific tools fitting Wikimedia specific Encyclopedic needs. I'm here asking for an official or strong statement from the Foundation and OSM, that expand OSM to fit Wikimedia needs will be add to the former Agenda of collaboration. The section "Thus, what next" provide several ways to process: by hidding some layers, adding GIS data, letting users collaboratively duplicate then translate linguistic layers and draw historical layers, we will create an Encyclopedic OSM. I'm conscient of the huge human work force this expansion will need, that what I would encourage -if its possible- the Greenspun found to support this project, if need. *End:* I Know I'm here flowding by just 2 emails a lot of concepts, a full system, and actually the fruit of 2-3 years of thinking. That's pretty huge. But as a wikicartographer, I state it again : expand OSM to Wikimedia's specific encyclopedic needs is the path we *HAVE TO* walk, sooner or later. Also, Hoping an strong statement from the Wikimedia fountation and OSM leaders, Regards, ---- Hugo LOPEZ (French), User:Yug (wikigraphist) Institute of Innovation, Technology and Management (Master 1) NCHU, Taizhong, Taiwan.

1 0

planet-090916.osm.bz2 - inconsistent dump?
by Marcin Cieslak 21 Sep '09

21 Sep '09

I tried to import planet-090916.osm.bz2 into the postgres database using osmosis, using empty schema from: URL: http://svn.openstreetmap.org/applications/utils/osmosis/trunk/script/contri… Revision: 17698 The dump process: time bzip2 -dc $HOME/import/planet-090916.osm.bz2 | \ $HOME/osmosis/trunk/bin/osmosis \ --read-xml file=-\ --write-apidb-0.6 authFile=$HOME/import/planet-authfile.txt failed after taking 26 hours and 415GB of space with: org.openstreetmap.osmosis.core.OsmosisRuntimeException: Unable to load current way nodes. (...) Caused by: org.postgresql.util.PSQLException: ERROR: insert or update on table "current_way_nodes" violates foreign key constraint "current_way_nodes_node_id_fkey" Detail: Key (node_id)=(497587545) is not present in table "current_nodes". My current_nodes contains now 434807934 rows and current_ways 12050. The highest numbered node is 497541099 and way is 1999800. Is this inconsistency of the planet.osm file or am I doing something wrong? Is there any way to recover from this or should I restart the whole process from scratch? Which dump would you recommend? -- << Marcin Cieslak // saper(a)saper.info >>

2 1

Marcin Cieslak (saper) now has access to ptolemy and ortelius
by Ævar Arnfjörð Bjarmason 19 Sep '09

19 Sep '09

On Sat, Sep 12, 2009 at 11:32 AM, Ævar Arnfjörð Bjarmason <avarab(a)gmail.com> wrote: > Marcin Cieslak (saper) which was at Wikimania 2009 and he's excited > about helping set up our OSM system on the ptolemy and ortelius > servers (see http://lists.wikimedia.org/pipermail/wikitech-l/2009-September/045131.html). > He wants to help set up the database / tile rendering aspect (which is > pretty much all we're doing). > > Here are his details as required for server admins: > > * Name: Marcin Cieślak > * Email: Marcin Cieslak <saper(a)saper.info> > * Address: [CUT OUT] > > And he's agreed to follow our privacy policy: > http://wikimediafoundation.org/wiki/Privacy_policy > > (not that there are any actual privacy concerns, these servers don't > have any access to private data as explained in the wikitech-l > posting) > > If you approve I'll take care of setting up his accounts on those servers. Mark gave the OK. I've created the user saper on both boxes. Marcin, you should be able to: ssh ptolemy.esams.wikimedia.org ssh ortelius.esams.wikimedia.org Here's the notes I kept when setting up Cassini: https://wiki.toolserver.org/view/OpenStreetMap_server/Setup_notes It would be very helpful if you continued updating that wiki page (or related pages) with the stuff you do. Open issues on the servers that need to be solved: * They need to be partitioned. There's some empty space on /dev/sd* that hasn't been partitioned (> 1TB) * Evidently hardy's kernel doesn't like the RAID card on these boxes. So the kernel needs to be upgraded, probably to jaunty-server Have fun!

6 20

Recent OSM replication issues
by Marcin Cieslak 19 Sep '09

19 Sep '09

An interesting thread from osm developers mailing list re replication methods: http://thread.gmane.org/gmane.comp.gis.openstreetmap.devel/17000/focus=17002 -- << Marcin Cieslak // saper(a)saper.info >>

2 1

Where we are now on getting OpenStreetMap into Wikipedia and what we need to do
by Ævar Arnfjörð Bjarmason 11 Sep '09

11 Sep '09

Hello there. This is a quick status update on the project to get OpenStreetMap maps into Wikipedia and on the Wikimedia/OpenStreetMap toolserver setup. For those that don't know what it's all about we're: * Setting up a testing platform (ptolemy & ortelius) to serve OSM maps in Wikipedia which can be rolled into production * Setting up a toolserver (cassini) which interested parties can use to write tools that use OSM data. And combine it with Wikimedia data if they want. Here's an (outdated!) wiki page with some more info: http://meta.wikimedia.org/wiki/OpenStreetMap And here's a recent talk I gave at Wikimania discussing the current status: http://wikimania2009.wikimedia.org/wiki/Proceedings:143 Until now we only had 1/3 machines active & accessible due to various combinations of waiting for hardware, people being busy and it being unclear who actually got access to those machines that I won't go into. That one machine was the nascent WMOSM Toolserver Cassini. I set up a prototype multilingular rendering (since ptolemy and ortelius weren't available at the time) which you can see here: http://cassini.toolserver.org/tile-browse/ What we need to to currently is: * Admins to set up ptolemy / ortelius so that they replicate the DB / mirror tiles * Get interested users/developers to *use* cassini for their tools so we can get neat stuff like the multilingular-country-list (http://cassini.toolserver.org/~mazder/multilingual-country-list/). Sign up here: https://wiki.toolserver.org/view/Account_request * Cassini also needs some admin love * Work on this buglist (and more bugs) to get OSM into Wikipedia: http://tinyurl.com/nv2sap I did most of this on Cassini (see setup notes: http://tinyurl.com/mbblj3) but I have limited time on it (especially until Christmas) and system administration isn't my strong suit. So unless we get other people to help this project is going to go *slooowly* and you won't have OSM on Wikipedia until 2010. Before WM2009 we had the unfortunate problem of interested parties needing to do the above not getting access due to the issues above. However the machines are up *now* and during WM2009 uncertainties about who could grant access were finally solved (brion will be dictator). So, any potential admins for ptolemy and ortelius will have to: 1. Be qualified & motivated Preferably someone who's worked with the OSM toolchain or is willing to learn. If you're maintaining your own ad-hoc rendering somewhere and are running out of server space you'll probably be motivated to get this working sooner. 2. Reveal their name & address to the Wikimedia foundation That's a requirement Wikimedia requires of all server administrators. 3. Agree to Wikimedia's privacy policy URL: http://wikimediafoundation.org/wiki/Privacy_policy ptolemy and ortelius are otherwise distinct servers on the Wikimedia network so this amounts to basically not being silly and running a Quake III server on them, or nmap-ing the Internet. Cassini is more sensitive and harder to gain access to since root admins on Cassini have access to private data about Wikimedia users (e.g. raw database access, login cookies and so on). But in both cases we should be able to give elevated non-Unix-root privileges. All of this pending approval by Wikimedia of course.

1 0

TomTom Launches Open Source Navigation Project
by Daniel Kinzler 11 Sep '09

11 Sep '09

HI all I just stubeled uppon an annoucement [1] that TomTom (make of GPS navigation devices) will launch an OSS project for location aware services/data, called OpenLR [2]. They call it a "universal location referencing technology" and call it "map-agnostic". Not quite sure what's behind it - a collection of data layer? an protocol for supplying and polling such data? I didn't dig deep, just though it might interest you... -- daniel [1] http://ostatic.com/blog/tomtom-launches-open-source-navigation-project [2] http://www.tomtom.com/page/openLR -- Daniel Kinzler Software Developer Wikimedia Deutschland Phone +49 30 219 158 260 Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us achieve that! http://spenden.wikimedia.de/ Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

3 2

Maps interface to the users
by Marcin Cieslak 11 Sep '09

11 Sep '09

Hello, On a side of the extension discussion I asked myself a question: How should plain editors use the new maps? I can imagine the following simple things that most people would probably want to do first: 1. just put a static map in the article 2. overlay the static map with some simple layer of images (like it's done with templates using CSS) How should they do (1)? Our current extensions provide usually some tag with coordinates as parameters. Do you think it would be feasible that we could allow use of OSM URLs, so that the user can just go to OSM, pan and zoom as they wish, pick a permalink or shortlink and paste it into some MediaWiki tag? Any thoughts on solving (2) better? I thinking about something simpler than what we have now (since we should be able to provide custom layers anyway at some point). -- << Marcin Cieslak // saper(a)saper.info >>

3 3

Usage of Maps instead of SlippyMap
by jeroen De Dauw 07 Sep '09

07 Sep '09

Hey, After discussing with Ævar, we agreed that using the Maps extension [0] instead of SlippyMap to display OSM maps with OL is probably a good idea, assuming this is doable of course, which I think it is. I am able and willing to put quite some time into making the needed changes to Maps. Before I can really start though, it would be helpful if I had the most up to date code of SlippyMap, since a lot of it's current code can be re-used. Is this the one committed to the SVN trunk? (I've downloaded that code, but it's missing at least one file and giving other errors as well.) It would also be nice if the people who are working on this end of the mapping effort give me a poke, so efforts can be coordinated, and no one goes off to create duplicate or redundant functionality. If anyone has objections to using Maps instead of SlippyMap, please voice them, so we can discuss the advantages and disadvantages of using Maps. These are as I see it the most important functionality to-do's: * Migrate code from SlippyMap to Maps, mainly the static map handling * Add the ability to display maps without any markers on them. Currently maps has several parser functions, like display_point, which will display an error when you don't provide any coordinates instead of displaying an empty map. (Should be easy to do though.) * Optimize the code. Currenly Maps supports OpenLayers as mapping service, and allows you to display maps from a variety of mapping services. On top of that, the OL JS is far from optimal. Therefore I think it's best to simply add a new service to Maps (this is done via a hook-like system build in Maps), and create optimized handling for only OL+ OSM there, based on current SlippyMap JS. * Optionally (probably not required in the first version) add image-as-layer capabilities, allowing users to zoom and pan around high resolution images. Anything mission critical I'm missing there? [0]http://www.mediawiki.org/wiki/Extension:Maps Cheers -- Jeroen De Dauw * Forum: code.bn2vs.com * Blog: blog.bn2vs.com * Skype: rts.bn.vs -- Don't panic. Don't be evil.70 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65!

4 6

Dynamic POIs
by Jorge Chamorro 04 Sep '09

04 Sep '09

During the wikimania 2009 I was following this work : http://wiki.openstreetmap.org/wiki/OpenLayers_Dynamic_POI for wikimania - openstreetmap collaboration Please first check this url : http://osm.chamorro.com.ar/dpoi/ At this url you can see cassini localized tiles with info extracted from download.dbpedia.org dumps At low zoom levels we have a lot of info then we need to limit the info per tile. Now I use a random value but then I use anything else Limit it by category/subcategory/search keyword it's fine but I want to improve the system for a large number of points at this time. There are languages without tiles because I generate the index page from a list from dbpedia. Data are probably not correctly passed too This is a work in progress . -- sorry for my poor English --- I based my work on a minimal example . A more complex is here: http://www.freemap.sk/ Saludos , Jorge

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Maps-l September 2009