Hey,
I've got the SlippyMap [0] JS working with Maps [1]. Althoguh it's working, it's missing handling for some of the parameter users can use to customize maps of other services, like the controls they want on the map, or in case of OpenLayers, the layers they want to have available.
My question is which of the things should be implemented. I am creating this OSM service mainly for the mapping implementation for WM, so it makes sense to have it optimized as much for WM usage as possible. I'd appreciate it if someone who is 'responsible' for the outline of the mapping implmentation contacts me [2] about this.
In any case, once version 0.4 is released, which won't be long any more, everyone will be able to see how the OSM service is currently implemented, and give feedback on that. I'd like to have Maps suitable for WM usage by version 0.5 though.
[0]http://www.mediawiki.org/wiki/Extension:SlippyMap
[1] http://www.mediawiki.org/wiki/Extension:Maps
[2] http://www.mediawiki.org/wiki/User:Jeroen_De_Dauw#Contact_info
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!
Hey,
Since the discussion about the use of the Maps extension [0] to display
(static) maps, part of the identified work to make Maps suitable for this
purpose has been done.
These are the big todo's, and their current status:
* Make Maps completely modular, to enable removing any part of the
functionality that's not wanted, and ensure optimal performance.
This todo has been completed, partly in the last Maps release, 0.3.4, and
partly in the code for the next version. Things that can now be taken out
since they use a hook like system:
- Mapping services (so if we only want OpenLayers with OSM, no problem!)
- The big 'features'. If you don't want geocoding, parser functions,
semantic result formats or form inputs, just remove an includes.
- Geocoding services. If you don't want the Google Geocoder service, just
remove it, and use one of the others.
- Parser functions. Maps only supports display_map and display_point ATM,
but others (like display_route) can easily be added, and of course all of
them can be removed.
* Make maps able to display maps without any markers.
This functionality has been added, and is on SVN trunk [1]. It'll be part of
the upcoming 0.4 release [2] of Maps. Displaying a map with no markers can
now be done with the display_map parser function (maps with markers use
display_point(s)), which is handled by classes that only have the required
code for displaying a Map.
* Add an OSM optimized OL service.
The current code that handles OL in Maps is not optimized for OSM. Also, I
suspect the JS is far from optimal, even if you don't specifically look at
OSM handling. I've just started on this todo, and am attempting to re-use as
much of the smart things done in SlippyMap. This is the final todo before
the 0.4 release.
* Add static map support.
No work has been done here yet. This is currently the only todo for v0.5.
Does anyone have remarks on the current code, or the way I'm planning to
adapt Maps? Also, are there things I'm missing in the list of requirements
for Maps to be suitable for WM usage?
Also, if anyone feels like helping me with the OSM optimisation or static
map functionality, or doing it yourself, just give me a poke, and I'll be
happy to coordinate efforts :)
[0] http://www.mediawiki.org/wiki/Extension:Maps
[1] http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Maps/
[2] http://www.mediawiki.org/wiki/Extension:Maps/Future#Maps_0.4
Cheers!
Jeroen De Dauw
Hello, I work the last two weeks on scripts that can show special
map-features for an area (bbox) on openlayers:
http://cassini.toolserver.org/~kolossos/streetlist/frames?bbox=13.54,50.95,…
(example Streetlist of Dresden)
With additionally parameters you can see also other objects than
"key=highway", so in the example you can see all rivers near Dresden:
http://cassini.toolserver.org/~kolossos/streetlist/streetinmap3.php?BBOX=13…
So you can see that this development goes in the direction of
Query-to-map[1] but is independent from Xapi and Google-API.
It was the question of 80n how fast a PostGIS solution can be, and I'm
really happy with the speed of the script. Database speed is not
everyting, in the past Query-to-map use a long running XSLT process to
transform OSM-XML to KML. Now I don't need this process because PostGIS
has nice functions to transform geometry to KML/GML or SVG. You can look
in the source code of my main scripts [2]. The other scripts are nearly
only simple html/js.
I use the "gis"-database on cassini which is used for our mapnik. I the
moment I use only the table "planet_osm_line". Could I get please some
indexes on columns like "name", "ref" and "highway"? I believe this
would optimize the perfomance further. Could we get for all common keys
[3] a column in the database?
Because I use KML you can use the same script also in GoogleEarth:
http://cassini.toolserver.org/~kolossos/streetlist/Netzwerk-Link-OSM-Map-fe…
It shows powerlines on Google Earth and reload after 5sec. when you stop
the camera and reloads with your actual BBOX. You can change the URL to
use it for other map-features.
To-Do list:
*Expand it the script to POI, areas and relations. Whats the best way to
do it? A UNION-sql command or a view in the database with all 4 kinds of
objects?
What a look should POIs have?
*Find the bug to get also the highest zoom-levels in Openlayers.
*Prove the database layout to optimize speed. (I have 2 weeks of
postgres experience, who has more? ;-) )
*Using perhaps the caching system like that of Query-to-map.
*Perhaps Openlayers is faster if I would use Mercator-projection inside
the KML.
*Documentation.
*Develop a stable & flexible URL schema to link of the spripts.
*For the street list: Usage Ajax instead of frames to speedup the
script. I the moment I replace the whole map. Who can help?
Use a A-Z register with the first
letter of the name to jump to the right position on the long list.
Who can work with me to make the script so strong, fast and secure that
it can be move to the productive wikimedia server system and be a part
of the map integration in wikipedia. My idea is that wikipedia editors
can add a map to an article and add some parameter to show really the
object of the article in the map. This would be for me thousand times
more fascinating than to show only the pure map. A new kind of
geocoding. But for this we would also need a process to render this
feature on the static map.
Greetings Kolossos
[1] http://wiki.openstreetmap.org/wiki/Query-to-map
[2]http://cassini.toolserver.org/~kolossos/streetlist/index-source.phphttp://cassini.toolserver.org/~kolossos/streetlist/street-to-kml2-source.php
[3]http://wiki.openstreetmap.org/wiki/Map_Features
Hello, we had this discussion in the past.
Could we get a XAPI-instance[1] on one of our servers?
I would like to use it for my Query-to-map project[2]. For other people
this service is also usefull.
In the moment the XAPI is so slow (2 kbit/s) that my script is
out-of-service.
I want to create a tool that shows the street names of all streets in a
bbox.
Every paper city map has such a list, so it seems usefull.
My first, basic step in this direction is the script "streetlist"[3].
(It use gis database on cassini table "plane_osm_roads". )
Than all entries in this list should be link to Query-to-map, so that
the user could see the streets in the map.
For this I would also need a running XAPI.
Because cassini had too few hard drive space the right place for XAPI
would be IMO on Ptolemy.
Who could decide this? Saper?
Other question, could cassini get more hard drive space? How usefull
would it be?
The concept of the the three servers usage is now other than on the
beginning.
Greetings Kolossos
[1]http://wiki.openstreetmap.org/index.php/Xapi
[2]http://wiki.openstreetmap.org/wiki/Query-to-map
[3]http://cassini.toolserver.org/~kolossos/streetlist/
can be useful ...............
Begin forwarded message:
Date: Wed, 30 Sep 2009 17:06:02 +0100
From: Brian Quinion <openstreetmap(a)brian.quinion.co.uk>
To: OpenStreetMap Geocoding <geocoding(a)openstreetmap.org>
Subject: [Geocoding] New geocoder test system
Hi,
After several false starts the goecoding tool I've been working on
seems to have succeeded in indexing the full planet file and it is now
available for people to experiment with here:
http://katie.openstreetmap.org/~twain/
Data is from 2 weeks ago (approx.) and will remain as is for a week or
so so people can try things after which I'll be using it as a test
system to try importing the daily diff files.
There are still several known problems:
1) No suggestion for miss-spelt words
I have code that produces suggestions but have not yet written the
interface for it.
2) Ordering of citys / towns by size
This is currently disabled because it is taking too long to index for
the planet. I hope to bring it back online shortly.
3) Filtering by viewbox
Currently broken and disabled (again)
4) Ordering of POI by distance
It finds the 10 nearest points (pub, station, whatever) but then
re-sorts them into an arbitrary order. It's an apples and oranges
problem caused by trying to order the points by a combination of
distance and importance and I'm still working on it.
5) 'more'
At the moment the code only shows up to 10 results and there is no way
to get more.
6) wrong name translation shown
Where the feature has names in other languages but not in the local
language (i.e. 'name:cy', but no 'name:en' only 'name') it can end up
showing the wrong version of the name. This is because I've not been
able to find a list of default languages for each country - if anyone
knows of such a list this is easily fixed!
7) Repetition in search results
Hopefully this is mostly fixed however some repetition is still
present where a road is in multiple areas / postcodes or where the
data is actually duplicated in OSM (I've avoided hiding the OSM
duplication so that problems can be found and fixed rather than just
hidden).
Please report other bugs to me either using the reporting tool built
into the site, by email or on IRC in #osm-geocoding. Before reporting
problems with addresses place check how the address was created using
the 'details' link next to each search result. The best way to
improve address information is to either create administrative
boundaries or convert places points into place areas (otherwise it has
to resort to 'nearest' which is always going to have problems).
In addition to HTML view results can also be retrieved in xml or json
format by adding 'format=xml' or format=json paramater to the url,
for example:
http://katie.openstreetmap.org/~twain/?format=xml&q=london
Feedback and bug reports, particularly regarding problems with
non-english searching appreciated.
--
Brian
_______________________________________________
Geocoding mailing list
Geocoding(a)openstreetmap.org
http://lists.openstreetmap.org/listinfo/geocoding
--
Jorge Luis Chamorro <chamorro(a)plug.org.ar>
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!