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.
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.
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 >>
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!
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.
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.
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 >>
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!
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