[Wikitech-l] Maps as article image?

[Strainu]

Hey folks,

The maps and aticle image have been good additions to the multimedia
capabilities in Wikipedia in the last decade, widely used on my home wiki.
For now, in Wikipedia the maps are also rendered as images and become
interactive only when clicked on. This makes them potential candidates for
being displayed as article images in article without a photo.

I would like to find out how complicated it would technically be to make
the article image extension also capable of using map images? I know this
is probably nowhere on the roadmap, I'm only interested in the technical
part of the idea.

Thanks,
   Strainu
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

Re: [Wikitech-l] Maps Modernization plan - FYI

[Seve Kim]

Hi Strainu,

I am a Product Manager at WMF. To answer your question, the Maps
Modernization effort doesn't interact much with the WMDE planned
improvements that you mentioned.

The Maps Modernization plan addresses more infrastructure needs.
With its completion, it will provide the maintainers of the maps
infrastructure with better monitoring, as an example. This will help better
prevent and address outages and ensure the reliability of maps as a service.

I believe the WMDE improvements are more client-facing or user-facing
needs. Things like allowing for users to save their default map view or
better interactive maps. WMF has kept in contact with the Technical Wishes
team but I believe this work does not directly impact the planned
improvements.

Best,
Seve

On Mon, Mar 22, 2021 at 2:01 PM Strainu  wrote:

> Hi Erica,
>
> Thanks for the announcement, I'm glad to see some love given to Maps.
> Could you explain how this initiative interacts with the planned
> improvements from WMDE [3]?
>
> Thank you,
>Strainu
>
> [3] https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Geoinformation
>
>
> În lun., 22 mar. 2021 la 19:11, Erica Litrenta 
> a scris:
>
>> Greetings,
>>
>> This is a follow up from our last email some months ago (and a
>> crosspost). You may already have seen today's announcement from Legal about
>> the upcoming changes to the Maps Terms of Use. Here is an extra heads-up
>> that Wikimedia Maps are transitioning towards a more modern
>> architecture. The first phase of this transition will be replacing
>> Tilerator [0] with Tegola [1] as our vector tile server. This is a change
>> in the Maps infrastructure, so there should be little to no impact to the
>> end users’ experience.
>>
>> It is important that we are able to provide software that is sustainable
>> to support, before we can guarantee a reliable user experience. Wikimedia
>> Maps aim to provide Wikimedia users a consistent experience contributing to
>> and learning about geoinformation. To achieve this goal, we will empower
>> those engineers maintaining the Wikimedia Maps infrastructure to do so with
>> ease and low effort.
>>
>> If you want to learn more, please head to mediawiki.org [2], where you
>> will also find a Questions & Answers section.
>>
>> Thanks, and take care,
>>
>> Erica Litrenta (on behalf of the Product Infrastructure team)
>>
>> [0] https://wikitech.wikimedia.org/wiki/Maps/Tilerator
>>
>> [1] https://tegola.io/
>> [2] https://www.mediawiki.org/wiki/Wikimedia_Maps/2021_modernization_plan
>>
>> --
>>
>> --
>>
>>
>> Erica Litrenta (she/her)
>>
>> Manager, Community Relations Specialists
>>
>> Wikimedia Foundation 
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


-- 

*Seve Kim* *(he/him)*
Product Manager, Platform
Wikimedia Foundation 

*   Wikipedia turns 20!
*
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps Modernization plan - FYI

[Strainu]

Hi Erica,

Thanks for the announcement, I'm glad to see some love given to Maps. Could
you explain how this initiative interacts with the planned improvements
from WMDE [3]?

Thank you,
   Strainu

[3] https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Geoinformation


În lun., 22 mar. 2021 la 19:11, Erica Litrenta  a
scris:

> Greetings,
>
> This is a follow up from our last email some months ago (and a crosspost).
> You may already have seen today's announcement from Legal about the
> upcoming changes to the Maps Terms of Use. Here is an extra heads-up that 
> Wikimedia
> Maps are transitioning towards a more modern architecture. The first phase
> of this transition will be replacing Tilerator [0] with Tegola [1] as our
> vector tile server. This is a change in the Maps infrastructure, so there
> should be little to no impact to the end users’ experience.
>
> It is important that we are able to provide software that is sustainable
> to support, before we can guarantee a reliable user experience. Wikimedia
> Maps aim to provide Wikimedia users a consistent experience contributing to
> and learning about geoinformation. To achieve this goal, we will empower
> those engineers maintaining the Wikimedia Maps infrastructure to do so with
> ease and low effort.
>
> If you want to learn more, please head to mediawiki.org [2], where you
> will also find a Questions & Answers section.
>
> Thanks, and take care,
>
> Erica Litrenta (on behalf of the Product Infrastructure team)
>
> [0] https://wikitech.wikimedia.org/wiki/Maps/Tilerator
>
> [1] https://tegola.io/
> [2] https://www.mediawiki.org/wiki/Wikimedia_Maps/2021_modernization_plan
>
> --
>
> --
>
>
> Erica Litrenta (she/her)
>
> Manager, Community Relations Specialists
>
> Wikimedia Foundation 
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Maps Modernization plan - FYI

[Erica Litrenta]

Greetings,

This is a follow up from our last email some months ago (and a crosspost).
You may already have seen today's announcement from Legal about the
upcoming changes to the Maps Terms of Use. Here is an extra heads-up
that Wikimedia
Maps are transitioning towards a more modern architecture. The first phase
of this transition will be replacing Tilerator [0] with Tegola [1] as our
vector tile server. This is a change in the Maps infrastructure, so there
should be little to no impact to the end users’ experience.

It is important that we are able to provide software that is sustainable to
support, before we can guarantee a reliable user experience. Wikimedia Maps
aim to provide Wikimedia users a consistent experience contributing to and
learning about geoinformation. To achieve this goal, we will empower those
engineers maintaining the Wikimedia Maps infrastructure to do so with ease
and low effort.

If you want to learn more, please head to mediawiki.org [2], where you will
also find a Questions & Answers section.

Thanks, and take care,

Erica Litrenta (on behalf of the Product Infrastructure team)

[0] https://wikitech.wikimedia.org/wiki/Maps/Tilerator

[1] https://tegola.io/
[2] https://www.mediawiki.org/wiki/Wikimedia_Maps/2021_modernization_plan

-- 

--


Erica Litrenta (she/her)

Manager, Community Relations Specialists

Wikimedia Foundation 
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Maps on wikidata

[Strainu]

Hi,

Thanks for the responses.

Pe sâmbătă, 9 mai 2020, Marius Hoch  a scris:

> Hi Strainu,
>
> as Michael already pointed out, the (currently hard-coded) zoom value can
> be found in CachingKartographerEmbeddingHandler::getWikiText.
>
> I guess we could try to derive the zoom from the precision of the
> coordinate (GlobeCoordinateValue::getPrecision), but other than that, I
> don't have a (nice and easy to implement) idea for improving this.


Other things that I have seen done in modules throughout the ecosystem are
using the bbox limits (P1333) and the surface. I am also considering
using the geo data from Commons, although that's in pretty bad shape (pun
intended). The precision is indeed another solution, although I would leave
it as the last option, since it depends more often on the data source than
on the subject itself. I hope some of those can be reused in php as well.

Any suggestions on how to prioritize those and/or other data sources in Lua
are welcome. I asked about the php code as I thought you might have some
"instance of"-based algorithm I could replicate.

Straini


> Cheers
> Marius
>
> On 5/9/20 12:42 AM, Michael Holloway wrote:
>
>> Hi Strainu,
>>
>> It's probably best if a Wikibase dev confirms, but I think this is what
>> you're looking for:
>> https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/ext
>> ensions/Wikibase/+/master/lib/includes/Formatters/CachingKar
>> tographerEmbeddingHandler.php#198
>>
>> -mdh
>>
>> On Fri, May 8, 2020 at 12:44 PM Strainu  wrote:
>>
>> Hey folks,
>>>
>>> Can someone point me to the code that decides which zoom to use for
>>> the maps that are displayed in the items with coordinates?
>>>
>>> Thanks,
>>> Strainu
>>>
>>> ___
>>> Wikitech-l mailing list
>>> Wikitech-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps on wikidata

[Marius Hoch]

Hi Strainu,

as Michael already pointed out, the (currently hard-coded) zoom value 
can be found in CachingKartographerEmbeddingHandler::getWikiText.


I guess we could try to derive the zoom from the precision of the 
coordinate (GlobeCoordinateValue::getPrecision), but other than that, I 
don't have a (nice and easy to implement) idea for improving this.


Cheers
Marius

On 5/9/20 12:42 AM, Michael Holloway wrote:

Hi Strainu,

It's probably best if a Wikibase dev confirms, but I think this is what
you're looking for:
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Wikibase/+/master/lib/includes/Formatters/CachingKartographerEmbeddingHandler.php#198

-mdh

On Fri, May 8, 2020 at 12:44 PM Strainu  wrote:


Hey folks,

Can someone point me to the code that decides which zoom to use for
the maps that are displayed in the items with coordinates?

Thanks,
Strainu

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps on wikidata

[Michael Holloway]

Hi Strainu,

It's probably best if a Wikibase dev confirms, but I think this is what
you're looking for:
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Wikibase/+/master/lib/includes/Formatters/CachingKartographerEmbeddingHandler.php#198

-mdh

On Fri, May 8, 2020 at 12:44 PM Strainu  wrote:

> Hey folks,
>
> Can someone point me to the code that decides which zoom to use for
> the maps that are displayed in the items with coordinates?
>
> Thanks,
>Strainu
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Maps on wikidata

[Strainu]

Hey folks,

Can someone point me to the code that decides which zoom to use for
the maps that are displayed in the items with coordinates?

Thanks,
   Strainu

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Maps-l] Old tiles.wfmlabs.org maps services need maintainers to keep them alive after december 18th

[Derk-Jan Hartman]

This is not a complete image. As there are no maintainers responding, it
requires deconstructing and analysing what is there now for this specific
tool, reworking that into a new system, testing that new system and then
switching from old to new.

DJ

On Thu, Dec 13, 2018 at 5:49 PM Andre Klapper 
wrote:

> On Thu, 2018-12-13 at 07:46 -0800, Pine W wrote:
> > Out of curiosity, what all would be involved in the OS change?
>
> See https://wikitech.wikimedia.org/wiki/News/Trusty_deprecation
>
> Cheers,
> andre
> --
> Andre Klapper | Bugwrangler / Developer Advocate
> https://blogs.gnome.org/aklapper/
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Maps-l] Old tiles.wfmlabs.org maps services need maintainers to keep them alive after december 18th

[Andre Klapper]

On Thu, 2018-12-13 at 07:46 -0800, Pine W wrote:
> Out of curiosity, what all would be involved in the OS change?

See https://wikitech.wikimedia.org/wiki/News/Trusty_deprecation

Cheers,
andre
-- 
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Maps-l] Old tiles.wfmlabs.org maps services need maintainers to keep them alive after december 18th

[Alex Monk]

I don't think WMF should be hiring contractors purely for the purpose of
supporting individual tools which are not in production.

On Thu, 13 Dec 2018 at 15:46, Pine W  wrote:

> Hi DJ,
>
> Out of curiosity, what all would be involved in the OS change?
>
> The bike layers could be a nontrivial loss for some folks.
>
> If no regular WMF staff are available for the OS changes and ongoing
> maintenance, and if the use of bike lanes (or other features) is
> significant in the opinion of the community, then I think that WMF
> contractor time should be an option for the changes and maintenance,
> although I would like to know how much that would cost before supporting
> that option, along with how strongly bike lanes (and other features
> supported by these servers) are wanted by the community. If the community
> has no strong feelings regarding the loss of these features and the
> contactor time would cost $30,000 in the first year then maybe the loss of
> these features is acceptable, but if there is significant community desire
> to maintain these features and the contractor time would cost $1,000 in the
> first year then I would probably support spending the money for contractor
> time for at least one year of additional service while WMF tries to recruit
> volunteers for future years. In the context of a $100 million annual
> budget, I am fairly confident that WMF could find $1,000 for an additional
> year of service.
>
>
> On Wed, Dec 12, 2018, 5:39 AM Derk-Jan Hartman <
> d.j.hartman+wmf...@gmail.com>
> wrote:
>
> > This is just another small reminder that, because the servers which host
> > tiles.wmflabs.org and wma.wmflabs.org (wikiminiatlas)  and overpass-wiki
> > run on a version of the OS (Ubuntu Trusty) that is no longer supported
> > (and hasn't been available for new instances since november 2017).
> >
> > These services need maintainers and support by community members in order
> > to keep them alive after dec 18th (after which wmflabs will phase out
> those
> > versions) and before the EOL of early 2019 of the OS. Unfortunately it
> > seems no one is stepping up so far to convert these machines.
> >
> > This issue is tracked at https://phabricator.wikimedia.org/T204506
> > As I was curious, I looked around on the tile server a bit and used what
> I
> > could find to update
> > https://wikitech.wikimedia.org/wiki/OSM_Tileserver#Technology_stack
> > This is all the information that I could gather, but i'm FAR from sure if
> > that is complete information and if I would break anything with a rebuild
> > basing myself on that info, so any information on missing elements etc.
> > would be appreciated. I've not gotten around to looking at wikiminiatlas.
> >
> > If the services are not rebuild then likely they will just disappear at
> > some point for all layer variants. This includes the mapnik, black and
> > white, hill shading, hike bike layers. As I have no idea how many users
> of
> > these services there are, it is hard to say what the effect of that would
> > be.
> >
> > DJ
> > ___
> > Maps-l mailing list
> > map...@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/maps-l
> >
> --
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Maps-l] Old tiles.wfmlabs.org maps services need maintainers to keep them alive after december 18th

[Pine W]

Hi DJ,

Out of curiosity, what all would be involved in the OS change?

The bike layers could be a nontrivial loss for some folks.

If no regular WMF staff are available for the OS changes and ongoing
maintenance, and if the use of bike lanes (or other features) is
significant in the opinion of the community, then I think that WMF
contractor time should be an option for the changes and maintenance,
although I would like to know how much that would cost before supporting
that option, along with how strongly bike lanes (and other features
supported by these servers) are wanted by the community. If the community
has no strong feelings regarding the loss of these features and the
contactor time would cost $30,000 in the first year then maybe the loss of
these features is acceptable, but if there is significant community desire
to maintain these features and the contractor time would cost $1,000 in the
first year then I would probably support spending the money for contractor
time for at least one year of additional service while WMF tries to recruit
volunteers for future years. In the context of a $100 million annual
budget, I am fairly confident that WMF could find $1,000 for an additional
year of service.


On Wed, Dec 12, 2018, 5:39 AM Derk-Jan Hartman 
wrote:

> This is just another small reminder that, because the servers which host
> tiles.wmflabs.org and wma.wmflabs.org (wikiminiatlas)  and overpass-wiki
> run on a version of the OS (Ubuntu Trusty) that is no longer supported
> (and hasn't been available for new instances since november 2017).
>
> These services need maintainers and support by community members in order
> to keep them alive after dec 18th (after which wmflabs will phase out those
> versions) and before the EOL of early 2019 of the OS. Unfortunately it
> seems no one is stepping up so far to convert these machines.
>
> This issue is tracked at https://phabricator.wikimedia.org/T204506
> As I was curious, I looked around on the tile server a bit and used what I
> could find to update
> https://wikitech.wikimedia.org/wiki/OSM_Tileserver#Technology_stack
> This is all the information that I could gather, but i'm FAR from sure if
> that is complete information and if I would break anything with a rebuild
> basing myself on that info, so any information on missing elements etc.
> would be appreciated. I've not gotten around to looking at wikiminiatlas.
>
> If the services are not rebuild then likely they will just disappear at
> some point for all layer variants. This includes the mapnik, black and
> white, hill shading, hike bike layers. As I have no idea how many users of
> these services there are, it is hard to say what the effect of that would
> be.
>
> DJ
> ___
> Maps-l mailing list
> map...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/maps-l
>
-- 

Pine
( https://meta.wikimedia.org/wiki/User:Pine )
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Maps in the language of your choice— try it out now on testwiki

[Joe Matazzoni]

You can now display maps in languages of your choice on testwiki. I made two 
pages to demonstrate the new features, on testwiki [1] and testwiki2 [2] 
(embedded maps on test2 are dynamic; those on test are static until you click 
to pop up an enlargement). 

By default, internationalized maps display in the language of the wiki (which 
is English for the testwikis). So to experiment with these features, you’ll 
want to use the two new mapframe parameters we’ve added. Just insert them into 
your mapframe code. 

lang=”xx”  Shows map labels in the language you specify with the short language 
codes used for each wiki.
lang=“local” Shows map labels in the languages of the territory mapped 
(essentially opting out of internationalization). 

Right now, internationalization works only with mapframe, not maplink (which 
should be working some time next week). You can read more about this new 
feature and how to use it on the Map Improvements 2018 project page, under 
Updates [3]. Our plan is to wait a week or two and assess user comments about 
the feature. At that point, we’ll decide whether to move forward with a general 
release or keep making fixes. 

So please try the new features out  and leave feedback on the Map Improvements 
2018 talk page [4] . We’re listening!

Yours,
Joe

[1] https://test.wikipedia.org/wiki/Map_internationalization_examples 

[2] https://test2.wikipedia.org/wiki/Map_internationalization_examples 

[3] https://www.mediawiki.org/wiki/Map_improvements_2018#Project_Updates 

[4] https://www.mediawiki.org/wiki/Talk:Map_improvements_2018 

_

Joe Matazzoni 
Product Manager, Collaboration
Wikimedia Foundation, San Francisco

"Imagine a world in which every single human being can freely share in the sum 
of all knowledge." 




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Maps-l] Now live: Shared structured data

[Susanna Ånäs]

Great work!

I'm happy with the new naming, Commons Datasets.

For historical maps we have been waiting to have a way to store data about
the rectification with the map image. Here it is! It brings us one notch
closer to being able to work with zoomable historical maps in Wikipedia.

Some have noted that the datasets are contrary to what Wikidata is about.
Instead, they are complementary! Not all data is either suitable for
Wikidata or licensed openly enough. Or not yet. Many great datasets can be
introduced to the Wikimedia online communities. The data owners will pay
attention to more open licensing, seeing their data being used. The
wikidatans will pick up interesting datasets and work to prepare missing
properties for them in Wikidata and ignite their bots. Sometimes the data
can just be used as is.

This is one part of the puzzle and it will be interesting to see how the
pieces fall into their places and evolve further.

In the coming few days there'll be time to digest and experiment.

Happy holidays
Susanna

2016-12-23 5:22 GMT+02:00 Bohdan Melnychuk :

> Yay :)
>
> As someone who already has plans to actively use it in both my metapedian
> role (e.g. CEE Spring article writing contest statistics data for building
> Graphs from being stored like https://meta.wikimedia.org/w/
> index.php?title=User:BaseBot/CEES/MMXVI/Per_country_sums_(
> general)=edit
> 
> to a better format of https://commons.wikimedia.org/
> wiki/Data:Wikimedia/CEE_Spring/Statistics/MMXVI/Per_
> country_sums_(general).tab which can be turned by Lua to the same output
> but now with it being controlled on wiki rather than bot code part) and
> exopedianish for actual articles I think it is wonderful.
>
> I do think that it needs tight cross linking with Wikidata and perfectly a
> way to run queries against both the sources at the same time (e.g. "give me
> the weather in all the current capitals in the date the comet Whatever was
> closest to the Sun the last time" or whatever else more useful thing may
> come into one's mind), but that does not deny the fact that it is very
> useful already.
>
> It can also be used as an intermediate location for data on the way to be
> imported to Wikidata, IMHO.
>
> --Base
>
>
> 22.12.2016, 21:31, "Yuri Astrakhan" :
>
> Gift season! We have launched structured data on Commons, available from
> all wikis.
>
> TLDR; One data store. Use everywhere. Upload table data to Commons, with
> localization, and use it to create wiki tables, lists, or use directly in
> graphs. Works for GeoJSON maps too. Must be licensed as CC0. Try this
> per-state GDP map demo, and select multiple years. More demos at the bottom.
> US Map state highlight
> 
>
> Data can now be stored as *.tab and *.map pages in the data namespace on
> Commons. That data may contain localization, so a table cell could be in
> multiple languages. And that data is accessible from any wikis, by Lua
> scripts, Graphs, and Maps.
>
> Lua lets you generate wiki tables from the data by filtering, converting,
> mixing, and formatting the raw data. Lua also lets you generate lists. Or
> any wiki markup.
>
> Graphs can use both .tab and .map directly to visualize the data and let
> users interact with it. The GDP demo above uses a map from Commons, and
> colors each segment with the data based on a data table.
>
> Kartographer (/) can use the .map data as an extra
> layer on top of the base map. This way we can show endangered species'
> habitat.
>
> == Demo ==
> * Raw data example
> 
> * Interactive Weather data
> 
> * Same data in Weather template
> 
> * Interactive GDP map
> 
> * Endangered Jemez Mountains salamander - habitat
> 
> * Population history
> 
> * Line chart 
>
> == Getting started ==
> * Try creating a page at data:Sandbox/.tab on Commons. Don't forget
> the .tab extension, or it won't work.
> * Try using some data with the Line chart graph template
> A thorough guide is needed, help is welcome!
>
> == Documentation links ==
> * Tabular help 
> * Map help 
> If you find a bug, create Phabricator ticket with #tabular-data tag, or
> comment on the documentation talk pages.
>
> == FAQ ==
> * Relation to Wikidata:  Wikidata is about "facts" (small pieces of
> information). Structured data is 

Re: [Wikitech-l] Maps

[Pine W]

Heh, I'm not sure if I should laugh or groan. IIRC, Erik, Yuvi and others
are prioritizing Labs reliability improvements for the next FY. I hope so.

Pine
On Mar 18, 2015 11:03 PM, Gerard Meijssen gerard.meijs...@gmail.com
wrote:

 Hoi

 What is meant by real hardware ?
 Can we have some at Labs please?
 Thanks,
  GerardM


   And will this service be hosted on
   Wikimedia Labs?
  
 
  No, on real hardware.
 
 
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps

[Gerard Meijssen]

Hoi

What is meant by real hardware ?
Can we have some at Labs please?
Thanks,
 GerardM


  And will this service be hosted on
  Wikimedia Labs?
 

 No, on real hardware.



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps

[Gerard Meijssen]

Hoi,
Yes, and that why the Labs hardware should not be talked down. It is or it
is not and truth apparently is in the eye of the one who sees it in its way.
Thanks,
 GerardM

On 19 March 2015 at 07:15, Pine W wiki.p...@gmail.com wrote:

 Heh, I'm not sure if I should laugh or groan. IIRC, Erik, Yuvi and others
 are prioritizing Labs reliability improvements for the next FY. I hope so.

 Pine
 On Mar 18, 2015 11:03 PM, Gerard Meijssen gerard.meijs...@gmail.com
 wrote:

  Hoi
 
  What is meant by real hardware ?
  Can we have some at Labs please?
  Thanks,
   GerardM
 
 
And will this service be hosted on
Wikimedia Labs?
   
  
   No, on real hardware.
  
  
  
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps

[Jeremy Baron]

On Mar 19, 2015 2:03 AM, Gerard Meijssen gerard.meijs...@gmail.com
wrote:
 What is meant by real hardware ?

https://en.wikipedia.org/wiki/Bare_metal_%28computer%29

 Can we have some at Labs please?

Labs nodes provisioned for and by labs users are virtual machines.

Labs has dedicated bare metal just for labs but it is not directly exposed
to labs users.

We could theoretically copy the approach at
http://www.rackspace.com/cloud/servers/onmetal but that probably would not
be a very good allocation of resources. (both capital and human) Labs is
well suited for virtualization. (nova and the other OSM, OpenstackManager
are not perfect. We can and do fix them and if needed can explore other
options. but bare metal is unnecessary for all labs workloads I'm aware of)

-Jeremy
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps

[Petr Bena]

One foundation to rule them all? :P

On Wed, Mar 18, 2015 at 10:06 AM, Max Semenik maxsem.w...@gmail.com wrote:
 Hi, just a quick note: as part of general search and discovery work, me and
 Yuri are resurrecting the project to have OpenStreetMap in Wikimedia
 starting in April. Because the initial part of this work will include
 researching options which will influence precise goals and this is yet to
 be done, we still can't commit to a precise timeline, but as a ballpark
 estimate I personally want to aim for serving PNG tiles at a reasonable,
 though not necessarily dynamic maps on every WP page scale by the end of
 Q4. Vector/multilingual maps would be the next stage. We will be mostly
 using Phabricator for planning,
 https://phabricator.wikimedia.org/tag/openstreetmap/ is my first pass on
 the outline of things to be done.

 Your comments and suggestions would be highly appreciated, please share
 your thoughts, ideas of projects that might use these maps, or just
 merciless critique! :D

 --
 Best regards,
 Max Semenik ([[User:MaxSem]])
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Maps

[Max Semenik]

Hi, just a quick note: as part of general search and discovery work, me and
Yuri are resurrecting the project to have OpenStreetMap in Wikimedia
starting in April. Because the initial part of this work will include
researching options which will influence precise goals and this is yet to
be done, we still can't commit to a precise timeline, but as a ballpark
estimate I personally want to aim for serving PNG tiles at a reasonable,
though not necessarily dynamic maps on every WP page scale by the end of
Q4. Vector/multilingual maps would be the next stage. We will be mostly
using Phabricator for planning,
https://phabricator.wikimedia.org/tag/openstreetmap/ is my first pass on
the outline of things to be done.

Your comments and suggestions would be highly appreciated, please share
your thoughts, ideas of projects that might use these maps, or just
merciless critique! :D

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps

[David Gerard]

Looks like just a collaboration :-)

https://www.mediawiki.org/wiki/OpenStreetMap
https://meta.wikimedia.org/wiki/OpenStreetMap
https://wiki.openstreetmap.org/wiki/Collaboration_with_Wikipedia

Obviously we should be doing our own tile rendering and serving, for example.


On 18 March 2015 at 09:09, Petr Bena benap...@gmail.com wrote:
 One foundation to rule them all? :P

 On Wed, Mar 18, 2015 at 10:06 AM, Max Semenik maxsem.w...@gmail.com wrote:
 Hi, just a quick note: as part of general search and discovery work, me and
 Yuri are resurrecting the project to have OpenStreetMap in Wikimedia
 starting in April. Because the initial part of this work will include
 researching options which will influence precise goals and this is yet to
 be done, we still can't commit to a precise timeline, but as a ballpark
 estimate I personally want to aim for serving PNG tiles at a reasonable,
 though not necessarily dynamic maps on every WP page scale by the end of
 Q4. Vector/multilingual maps would be the next stage. We will be mostly
 using Phabricator for planning,
 https://phabricator.wikimedia.org/tag/openstreetmap/ is my first pass on
 the outline of things to be done.

 Your comments and suggestions would be highly appreciated, please share
 your thoughts, ideas of projects that might use these maps, or just
 merciless critique! :D

 --
 Best regards,
 Max Semenik ([[User:MaxSem]])
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps

[Pine W]

Glad to hear of this idea. We've discussed potential collaborations with
OSM in Cascadia Wikimedians meetings.

Pine
On Mar 18, 2015 2:08 AM, Max Semenik maxsem.w...@gmail.com wrote:

 Hi, just a quick note: as part of general search and discovery work, me and
 Yuri are resurrecting the project to have OpenStreetMap in Wikimedia
 starting in April. Because the initial part of this work will include
 researching options which will influence precise goals and this is yet to
 be done, we still can't commit to a precise timeline, but as a ballpark
 estimate I personally want to aim for serving PNG tiles at a reasonable,
 though not necessarily dynamic maps on every WP page scale by the end of
 Q4. Vector/multilingual maps would be the next stage. We will be mostly
 using Phabricator for planning,
 https://phabricator.wikimedia.org/tag/openstreetmap/ is my first pass on
 the outline of things to be done.

 Your comments and suggestions would be highly appreciated, please share
 your thoughts, ideas of projects that might use these maps, or just
 merciless critique! :D

 --
 Best regards,
 Max Semenik ([[User:MaxSem]])
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps

[Max Semenik]

On Wed, Mar 18, 2015 at 4:01 PM, MZMcBride z...@mzmcbride.com wrote:

 I believe OpenStreetMap previously had a relationship with Wikimedia
 Germany and the Toolserver(?). I'm not sure if that endeavor is related to
 this one. And I'm not sure what the scopes of these projects are.


Toolserver's gone, right?


 It looks like this new project would be the Wikimedia Foundation acting as
 both the (tile)server and the client, using data from OpenStreetMap. Is
 that correct?


Yes.


 If so, will the tileserver be considered a public service
 for use outside of Wikimedia wikis?


TBD.


 And will this service be hosted on
 Wikimedia Labs?


No, on real hardware.


 Expanding the mediawiki.org and Meta-Wiki pages to include more
 information about the history here would be great.


Hey, we're still working on fulfilling our previous commitments. Everything
will come, just not instantaneously;)

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps

[MZMcBride]

David Gerard wrote:
Looks like just a collaboration :-)

https://www.mediawiki.org/wiki/OpenStreetMap
https://meta.wikimedia.org/wiki/OpenStreetMap
https://wiki.openstreetmap.org/wiki/Collaboration_with_Wikipedia

Obviously we should be doing our own tile rendering and serving, for
example.

Thanks for these links.

I believe OpenStreetMap previously had a relationship with Wikimedia
Germany and the Toolserver(?). I'm not sure if that endeavor is related to
this one. And I'm not sure what the scopes of these projects are.

It looks like this new project would be the Wikimedia Foundation acting as
both the (tile)server and the client, using data from OpenStreetMap. Is
that correct? If so, will the tileserver be considered a public service
for use outside of Wikimedia wikis? And will this service be hosted on
Wikimedia Labs?

Expanding the mediawiki.org and Meta-Wiki pages to include more
information about the history here would be great.

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Maps-l] Output from Zurich Hackathon - yet another maps extension!

[Dan Andreescu]

 FYI, Limn is also sort of taken in the MediaWiki/WMF namespace:
 https://www.mediawiki.org/wiki/Analytics/Limn


Yep, but that Limn is dying slowly.  If we do this new extension properly,
it will take its place.  As Erik said, this is not staffed for success
right now but it would address many shared needs.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Maps-l] Output from Zurich Hackathon - yet another maps extension!

[Jon Robson]

Update. There is now a Special:Map which when passed API parameters
can construct a map from the corresponding API request. This would
give us the opportunity to create maps around existing data. This
would support a Nearby map view.

See this link for more:
http://wikimaps-ext.wmflabs.org/wiki/Making_maps_via_the_API

All of this is very prototypal and can be removed if there is no need.
I plan to get this off Github and on to Gerrit sometime next week.

On Tue, May 20, 2014 at 6:48 PM, Dan Andreescu dandree...@wikimedia.org wrote:

 FYI, Limn is also sort of taken in the MediaWiki/WMF namespace:
 https://www.mediawiki.org/wiki/Analytics/Limn


 Yep, but that Limn is dying slowly.  If we do this new extension properly,
 it will take its place.  As Erik said, this is not staffed for success
 right now but it would address many shared needs.
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Maps-l] Output from Zurich Hackathon - yet another maps extension!

[Matthew Flaschen]

On 05/14/2014 12:43 PM, Dan Andreescu wrote:

* File namespace serving raw data from Commons (where people are familiar
with take down notices and have the infrastructure to deal with that)


We shouldn't let copyright considerations dictate which WMF project 
hosts the data.  https://wikimediafoundation.org/wiki/Designated_agent 
covers all the projects.


The WMF is responsible for handling official DMCA takedown notices 
(which means they should generally be covered by the Safe Harbor),


However, editors (e.g. on Wikipedia, Commons, etc.) can and do take a 
proactive role in fighting copyright infringement above and beyond that.


Matt Flaschen

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Maps-l] Output from Zurich Hackathon - yet another maps extension!

[Jon Robson]

Tim I completely agree. This is something we need to setup.
Patches very much welcomed! :-)



On Wed, May 14, 2014 at 7:51 AM, Tim Alder t...@alder-digital.de wrote:
 I think the most important feature is to create on serverside a
 thumbnail for each map by using something like http://phantomjs.org/
 This thumbnails should than be in the big WMF caches. The map would
 become interactively only in the case a user click on it.
 This would reduce the numbers of request for loading a page and JS
 overhead and it would increase the stability of the system.
 Without this feature I afraid to never see the extension live in Wikipedia.

 Other nice features you can see at umap.openstreetmap.fr:
 *Choosing different backgrounds
 *POIs with interactive descriptions
 *Geometry import from OSM (WIWOSM)
 *different layers
 *...

 Greeting Tim alias Kolossos


 Am 14.05.2014 00:34, schrieb Jon Robson:
 During the Zurich hackathon, DJ Hartman, Aude and I knocked up a
 generic maps prototype extension [1]. We have noticed that many maps
 like extensions keep popping up and believed it was time we
 standardised on one that all these extensions could use so we share
 data better.

 We took a look at all the existing use cases and tried to imagine what
 such an extension would look like that wouldn't be too tied into a
 specific use case.

 The extension we came up with was a map extension that introduces a
 Map namespace where data for the map is stored in raw GeoJSON and can
 be edited via a JavaScript map editor interface. It also allows the
 inclusion of maps in wiki articles via a map template.

 Dan Andreescu also created a similar visualisation namespace which may
 want to be folded into this as a map could be seen as a visualisation.
 I invite Dan to comment on this with further details :-)!

 I'd be interested in people's thoughts around this extension. In
 particular I'd be interested in the answer to the question For my
 usecase A what would the WikiMaps extension have to support for me to
 use it.

 Thanks for your involvement in this discussion. Let's finally get a
 maps extension up on a wikimedia box!
 Jon

 [1] https://github.com/jdlrobson/WikiMaps

 ___
 Maps-l mailing list
 map...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/maps-l



 ___
 Maps-l mailing list
 map...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/maps-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Maps-l] Output from Zurich Hackathon - yet another maps extension!

[Dan Andreescu]

Thanks for starting this Jon, the end result is going to be awesome.  So
here's how I see things, it's roughly along the lines of what you've been
saying:

Server-side rendering and scaling is important.  This is one of the main
reasons I picked Vega [2] for my hack.  The same visualization grammar can
be used to generate png or svg [2].  I see the approach to visualization as
being similar to Parsoid:

* user creates a visualization (with a visual editor) and saves
* Vega parses that server side and generates an image, then refreshes the
caches accordingly
* a transcluded visualization renders the image from cache as a link to the
interactive version
* when the link is clicked, something like MediaViewer shows the
interactive visualization
* alternatively, we can allow editors to show the interactive version in
the transclusion itself, but that has performance implications until
browser caches are filled.

Now a little bit about where I see the Map namespace.  A visualization in
the world of Vega has three parts:

* Data (one or more sets of data, can be geojson, topojson, tsv, csv,
layers from OSM [3], OHM [4], etc.)
* Transformations on that data (scales, normalization, etc.)
* Marks (visual representations)

Transformations and Marks can be written by hand or by a visual editor that
introspects the specification to show what's possible.  Data to me is the
tricky part.  We may need to restrict Vega to only consume open data that's
hosted and curated by us, and that could be done in a few different ways:

* Namespaces like the Maps namespace that enables awesome collaborative
editing of geojson
* Datasets in WikiData using an alternative data model
* File namespace serving raw data from Commons (where people are familiar
with take down notices and have the infrastructure to deal with that)

But yes, I do see the Maps namespace as one of the sources of data that we
could visualize with Vega.  And recent developments in Vega make me feel
that it's really a solid choice for generic visualization.  We have
interactivity, headless mode, a seemingly clear path to a visual editor via
introspection of the grammar specification, and pretty much everything I
can think of needing from such a tool.

For the short term, I think further exploration of the Map namespace is
great, but I think generic visualization work could go into the
Visualization namespace.  My suggestion for a name for this namespace may
seem a bit obscure.  It's a word that means to illuminate: Limn [5].
 There's an old project by that name of which I'm not very fond (despite
writing some of it myself), but I've always thought the word was beautiful
and fit.  To what Antoine was saying earlier, we should illuminate the
world's knowledge with beautiful visualizations.


[1] https://github.com/trifacta/vega
[2] https://github.com/trifacta/vega/wiki/Headless-Mode
[3] OSM - Open Street Maps http://wiki.openstreetmap.org/wiki/Main_Page
[4] OHM - Open Historical Maps
http://wiki.openstreetmap.org/wiki/Open_Historical_Map
[5] Limn - depict or describe in painting or words:
https://github.com/wikimedia/mediawiki-extensions-Limn


On Wed, May 14, 2014 at 9:43 AM, Jon Robson jrob...@wikimedia.org wrote:

 Tim I completely agree. This is something we need to setup.
 Patches very much welcomed! :-)



 On Wed, May 14, 2014 at 7:51 AM, Tim Alder t...@alder-digital.de wrote:
  I think the most important feature is to create on serverside a
  thumbnail for each map by using something like http://phantomjs.org/
  This thumbnails should than be in the big WMF caches. The map would
  become interactively only in the case a user click on it.
  This would reduce the numbers of request for loading a page and JS
  overhead and it would increase the stability of the system.
  Without this feature I afraid to never see the extension live in
 Wikipedia.
 
  Other nice features you can see at umap.openstreetmap.fr:
  *Choosing different backgrounds
  *POIs with interactive descriptions
  *Geometry import from OSM (WIWOSM)
  *different layers
  *...
 
  Greeting Tim alias Kolossos
 
 
  Am 14.05.2014 00:34, schrieb Jon Robson:
  During the Zurich hackathon, DJ Hartman, Aude and I knocked up a
  generic maps prototype extension [1]. We have noticed that many maps
  like extensions keep popping up and believed it was time we
  standardised on one that all these extensions could use so we share
  data better.
 
  We took a look at all the existing use cases and tried to imagine what
  such an extension would look like that wouldn't be too tied into a
  specific use case.
 
  The extension we came up with was a map extension that introduces a
  Map namespace where data for the map is stored in raw GeoJSON and can
  be edited via a JavaScript map editor interface. It also allows the
  inclusion of maps in wiki articles via a map template.
 
  Dan Andreescu also created a similar visualisation namespace which may
  want to be folded into this as a map could be seen as a 

Re: [Wikitech-l] Maps extension graphical editor.

[Jon Robson]

Slight user experience improvement you might want to make... I'd make
it so that if you click on a tool icon a second time it unselects. I'd
remove the hand tool and make that the function that is the default
when no tools are selected. This icon seems out of place to me as all
the others are things I can create.

On Thu, May 31, 2012 at 1:33 PM, Kim Eik k...@heldig.org wrote:
 Just did some updates on it, added a slider to handle the opacity fields,
 and a color picker for color fields.

 On Thu, May 31, 2012 at 11:48 AM, Strainu strain...@gmail.com wrote:

 Looks like some email bug. :) Let's try without anything behind the URL:


 http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.html

 2012/5/31 Daniel Werner daniel.wer...@wikimedia.de:
  Looks good and helpful to me. One thing not working yet is the marker
 icons
  switching color when assigned to a group. You could take the markers from
  the maps extension directly for that.
 
  By the way, the url is
  lwithout
  the - in the end.
 
  2012/5/31 Ole Palnatoke Andersen palnat...@gmail.com
 
  URL correction:
 
 
 http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.html-
  there was no space between this and and.
 
  On Thu, May 31, 2012 at 8:49 AM, Kim Eik k...@heldig.org wrote:
 
   Hi guys, i have created a simple map editor which works with the Maps
   extension, i'm looking for some feedback on your impression of it.
  
   please take a look @
  
  
 
 http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.htmland
   let me know what you think.
  
   and also, please note it's a work in progress. My idea is to implement
  this
   as a special page in the Maps extension so that people can easily
 create
   and edit maps.
  
   Cheers
   Kim
   ___
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org
   https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  
 
 
 
  --
  http://palnatoke.org * @palnatoke * +4522934588
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 
 
 
  --
  Daniel Werner
  Software Engineer
 
  Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin
  Tel. (030) 219 158 26-0
 
  http://wikimedia.de
 
  Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
  Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
 unter
  der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
  Körperschaften I Berlin, Steuernummer 27/681/51985.
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Jon Robson
http://jonrobson.me.uk
@rakugojon

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Maps extension graphical editor.

[Kim Eik]

Hi guys, i have created a simple map editor which works with the Maps
extension, i'm looking for some feedback on your impression of it.

please take a look @
http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.htmland
let me know what you think.

and also, please note it's a work in progress. My idea is to implement this
as a special page in the Maps extension so that people can easily create
and edit maps.

Cheers
Kim
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps extension graphical editor.

[Ole Palnatoke Andersen]

URL correction:
http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.html-
there was no space between this and and.

On Thu, May 31, 2012 at 8:49 AM, Kim Eik k...@heldig.org wrote:

 Hi guys, i have created a simple map editor which works with the Maps
 extension, i'm looking for some feedback on your impression of it.

 please take a look @

 http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.htmland
 let me know what you think.

 and also, please note it's a work in progress. My idea is to implement this
 as a special page in the Maps extension so that people can easily create
 and edit maps.

 Cheers
 Kim
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
http://palnatoke.org * @palnatoke * +4522934588
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps extension graphical editor.

[Daniel Werner]

Looks good and helpful to me. One thing not working yet is the marker icons
switching color when assigned to a group. You could take the markers from
the maps extension directly for that.

By the way, the url is
http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.htmlwithout
the - in the end.

2012/5/31 Ole Palnatoke Andersen palnat...@gmail.com

 URL correction:

 http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.html-
 there was no space between this and and.

 On Thu, May 31, 2012 at 8:49 AM, Kim Eik k...@heldig.org wrote:

  Hi guys, i have created a simple map editor which works with the Maps
  extension, i'm looking for some feedback on your impression of it.
 
  please take a look @
 
 
 http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.htmland
  let me know what you think.
 
  and also, please note it's a work in progress. My idea is to implement
 this
  as a special page in the Maps extension so that people can easily create
  and edit maps.
 
  Cheers
  Kim
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 



 --
 http://palnatoke.org * @palnatoke * +4522934588
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Daniel Werner
Software Engineer

Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin
Tel. (030) 219 158 26-0

http://wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps extension graphical editor.

[Strainu]

Looks like some email bug. :) Let's try without anything behind the URL:

http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.html

2012/5/31 Daniel Werner daniel.wer...@wikimedia.de:
 Looks good and helpful to me. One thing not working yet is the marker icons
 switching color when assigned to a group. You could take the markers from
 the maps extension directly for that.

 By the way, the url is
 lwithout
 the - in the end.

 2012/5/31 Ole Palnatoke Andersen palnat...@gmail.com

 URL correction:

 http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.html-
 there was no space between this and and.

 On Thu, May 31, 2012 at 8:49 AM, Kim Eik k...@heldig.org wrote:

  Hi guys, i have created a simple map editor which works with the Maps
  extension, i'm looking for some feedback on your impression of it.
 
  please take a look @
 
 
 http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.htmland
  let me know what you think.
 
  and also, please note it's a work in progress. My idea is to implement
 this
  as a special page in the Maps extension so that people can easily create
  and edit maps.
 
  Cheers
  Kim
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 



 --
 http://palnatoke.org * @palnatoke * +4522934588
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




 --
 Daniel Werner
 Software Engineer

 Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin
 Tel. (030) 219 158 26-0

 http://wikimedia.de

 Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
 Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
 der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
 Körperschaften I Berlin, Steuernummer 27/681/51985.
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps extension graphical editor.

[Kim Eik]

Just did some updates on it, added a slider to handle the opacity fields,
and a color picker for color fields.

On Thu, May 31, 2012 at 11:48 AM, Strainu strain...@gmail.com wrote:

 Looks like some email bug. :) Let's try without anything behind the URL:


 http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.html

 2012/5/31 Daniel Werner daniel.wer...@wikimedia.de:
  Looks good and helpful to me. One thing not working yet is the marker
 icons
  switching color when assigned to a group. You could take the markers from
  the maps extension directly for that.
 
  By the way, the url is
  lwithout
  the - in the end.
 
  2012/5/31 Ole Palnatoke Andersen palnat...@gmail.com
 
  URL correction:
 
 
 http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.html-
  there was no space between this and and.
 
  On Thu, May 31, 2012 at 8:49 AM, Kim Eik k...@heldig.org wrote:
 
   Hi guys, i have created a simple map editor which works with the Maps
   extension, i'm looking for some feedback on your impression of it.
  
   please take a look @
  
  
 
 http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.htmland
   let me know what you think.
  
   and also, please note it's a work in progress. My idea is to implement
  this
   as a special page in the Maps extension so that people can easily
 create
   and edit maps.
  
   Cheers
   Kim
   ___
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org
   https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  
 
 
 
  --
  http://palnatoke.org * @palnatoke * +4522934588
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 
 
 
  --
  Daniel Werner
  Software Engineer
 
  Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin
  Tel. (030) 219 158 26-0
 
  http://wikimedia.de
 
  Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
  Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
 unter
  der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
  Körperschaften I Berlin, Steuernummer 27/681/51985.
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Maps and Semantic Maps git repos read-only

[Jeroen De Dauw]

Hey,

A little over a month ago I noticed that most of the history of the Maps
and Semantic Maps git repos was missing. I asked about this on IRC and
wrote the list, but it seems like it's not going to get fixed without me
doing the work. So I just spend 2 hours figuring out how to do this, and
although what I came up with is not ideal (it has me as comitter for all
the 30 or so changes that happened since the git migration), it fixes the
history issue. Now I have 2 working git repos, but no idea of how to get
this onto gerrit. Everything I tried got rejected, so I put the repos on
github and made the ones on gerrit read-only for now. I'd be very grateful
if someone could replace the stuff on gerrit with these, or better yet,
with a proper fixed version of the repos with full history.

* https://github.com/JeroenDeDauw/Maps
* https://github.com/JeroenDeDauw/SemanticMaps

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps and Semantic Maps git repos read-only

[Chad]

On Tue, May 15, 2012 at 3:37 PM, Jeroen De Dauw jeroended...@gmail.com wrote:
 Hey,

 A little over a month ago I noticed that most of the history of the Maps
 and Semantic Maps git repos was missing. I asked about this on IRC and
 wrote the list, but it seems like it's not going to get fixed without me
 doing the work. So I just spend 2 hours figuring out how to do this, and
 although what I came up with is not ideal (it has me as comitter for all
 the 30 or so changes that happened since the git migration), it fixes the
 history issue. Now I have 2 working git repos, but no idea of how to get
 this onto gerrit. Everything I tried got rejected, so I put the repos on
 github and made the ones on gerrit read-only for now. I'd be very grateful
 if someone could replace the stuff on gerrit with these, or better yet,
 with a proper fixed version of the repos with full history.

 * https://github.com/JeroenDeDauw/Maps
 * https://github.com/JeroenDeDauw/SemanticMaps

 Cheers


To do this, you'll need to do a force push (since you're rewriting history).
Grant your group Push permissions on refs/* with the Force option
checked.

Please revoke it as soon as you're done because it opens your repo
up to Breaking Things if people do forces all the time.

The actual push will be `git push -f [remote] [branch]`

-Chad

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps and Semantic Maps git repos read-only

[Jeroen De Dauw]

Hey,

With some additional help of chad on IRC the fixed version of the repos
have now been pushed to gerrit, so the stuff is writable again :)

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Maps extension image layer enhancements

[Daniel Werner]

Hi,

Actually, I sent a mail to the maps mailing list already but there was 
no feedback at all so I am taking Jeroens advice and try it again here, 
there might be some users using maps and waiting for the image maps 
feature. I already included some of the features suggested in my last 
mail to map...@lists.wikimedia.org a little different though.

Recently I have been fixing the Maps extension openlayers image feature 
to use images as maps again (the feature was broken around Maps 1.0).

Besides fixing the feature for the next version of maps, I have 
implemented the following features already:
* Additional parameters on layer pages (unit, maxScale, minScale) to 
better control how the map is being displayed.
* Markers can have a group, each group is represented as one overlay 
layer and has its own marker colour (for default markers).
* the display_... functions/tags using a layer: page store this in the 
database, layer-pages show which pages are using the layer and pages 
using a layer will be purged when the layer changes.
* Database table for layers which should increase performance and allows 
to define several layers in one page to group them. Using the layer page 
name will include all of these group members into the base map-selection 
of a map. Also, a layer name= type=...properties.../layer tag is 
used to define layers now. Via 'name' the layer can have a name so a 
specific group member layer can be used instead of the whole group of 
layers defined on the same layer-page.

now I am writing because I am planing on implementing some more features 
which I need some opinion on:



1. I have implemented first attempts of allowing overlay maps. The 
overlay feature introduces the attribute 'overlays' for 'display_map' 
and 'display_point' like:
display_map service=openlayers layers=Moon Map overlays=Moon 
Station, Moon City0,0/display_map
where 'Moon Station' and 'Moon City' could be smaller maps located on 
'Moon Map', simply images with more detail where you can zoom in from a 
overall view of moon into a detail view of the base and the city. The 
cool thing about this is, that overlay maps also could be displayed as 
baselayers if you use them with the 'layers' parameter instead (since 
they must have a layer: page anyway)

This works, but it doesn't make much sense without coordinates for the 
overlays. So I am thinking about a appropriate syntax but can't come up 
with anything nice:
display_map service=openlayers layers=Moon Map overlays=Moon 
Station|20;40, Moon City|100;400,0/display_map
for example wouldn't be very consistent syntax compared to the other map 
syntax and I don't even want to think about #display_points which has 
some weird syntax compared to display_points
How about:
display_map service=openlayers layers=Moon Map overlays=Moon 
Station|Station, Moon City|City addresses=Station (20,40), City 
(100,40)0,0/display_map
So we would first declare some named addresses and assign them to 
coordinates, from then on we can use the names for image layers just 
like in mapping services like bing or google maps where you can just 
write 'New York' instead of the actual geographical coordinates. And not 
using the () within 'overlays' has the advantage that layer sites still 
can contain '(' and ')' within the site name. It also allows to use the 
addresses for markers like:
display_points service=openlayers layers=Moon Map overlays=Moon 
Station|Station, Moon City|City addresses=Station (20,40), City (100,40)
Station | Moon Station | This is the moon station | station.png | Group 1
/display_map
So instead of using coordinates we can use names as coordinates for 
markers within image layers as well!
This goes even one step further with the following...

2. ...allowing to define addresses within the layer page. This could be 
a parameter 'addresses' which contains coordinates and names of 
addresses which can be used for overlays and markers for 'display_point' 
and for overlays using 'display_map'.
This could look like:
layer type=image
source = moon.jpg
...
addresses = station (20,40), city (100,40), 
/layer

addresses would be case-insensitive and would even make the use of the 
'addresses' parameter within the display functions obsolete when using 
overlays but the main advantage would of course be that markers can be 
added very fast and without searching for coordinates first since all 
important coordinates are described already.
'addresses' parameter of display functions will overwrite if one name is 
given there and on a layer page.

3. its difficult with units. Layers can have different units like 
degree, km, miles... I didn't look into how it works if markers with 
units are defined in display_marker if there are layers with different 
units. Perhaps we should allow coordinates with units like 20km,200m 
to make it clear. This could also be included in layer pages so we can 
say left-extend=20km and stuff like that instead of having a unit 
attribute.
There 

Re: [Wikitech-l] Maps extension image layer enhancements

[Platonides]

Daniel Werner wrote:
 3. its difficult with units. Layers can have different units like
 degree, km, miles... I didn't look into how it works if markers with
 units are defined in display_marker if there are layers with different
 units. Perhaps we should allow coordinates with units like 20km,200m
 to make it clear. This could also be included in layer pages so we can
 say left-extend=20km and stuff like that instead of having a unit
 attribute.
 There might me more simple solutions though, have not really looked into
 that yet.

ParserFunctions extension is able to convert between units, so you could 
accept mixed units and canonalize to your prefered one.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Maps/Semantic Maps - KML visualisation status

[Benedikt Kämpgen]

Hi Jeroen,

I have seen that you released new versions of Maps/Semantic Maps, great,
thanks!

Could you please give me some information about the current status of KML
visualisation in Maps/Semantic Maps?

With the current version, I haven't been able to visualise KML files,
although mentioned [1].

[1] http://mapping.referata.com/wiki/Google_Maps_v3 

For 7.x I had added support for automatic centering and external/internal
KML files. Do they still work?

It would be great if you could give me some pointers. Or maybe I can help
you improving the KML support.

Best,

Benedikt

--
AIFB, Karlsruhe Institute of Technology (KIT)
Phone: +49 721 608-47946 
Email: benedikt.kaemp...@kit.edu
Web: http://www.aifb.kit.edu/web/Hauptseite/en 



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps/Semantic Maps - KML visualisation status

[Jeroen De Dauw]

Hey,

 Could you please give me some information about the current status of KML
visualisation in Maps/Semantic Maps?

The latest release of Maps only has experimental support for KML. The
upcoming 1.0.3 release will have better support for KML (and Google Earth!),
which is already in place, and which I'll document soonish (before the
release).

 For 7.x I had added support for automatic centering and external/internal
KML files. Do they still work?

These improvements made on the 0.7.x branch are not compatible with trunk,
and are also made for Google Maps v2, which I'm not longer supporting
(although you can still use it with the latest version of Maps). The current
code on trunk does have support for automatically adjusting the zoom level
so all KML overlays can be seen on the map.

 Or maybe I can help you improving the KML support.

I'd like to release 1.0.3 before any real changes are made, so if you want
to add in functionality, I'll hurry up and get 1.0.3 released :)

In any case, the JS doing the KML stuff is in the function on line 108 here:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Maps/includes/services/GoogleMaps3/jquery.googlemap.js?view=markup

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Maps: marker specific parameters

[Jeroen De Dauw]

Hey,

Currently the Maps extension [0] allows you to specify marker specific data
[1] (a titel, further text, and the icon to use). The way this is done is
not very clean, and needs improvement. Someone poked me about this at
Wikimania, but I don't know how to improve upon the current syntax, hence
this discussion.

What's bad about the current approach:
* A 3rd level of parameter is needed, which is rather insane. (The first
level are the regular parser function parameters, separated with vertical
lines. The second level are coordinates or addresses, separated by
semicolons. The third level for the marker specific data uses tildes as
delimiters.)
* Not very readable.
* Unsuited for long text.
* Excludes all the delimiters from usage in the text.
* Problems with links in the wikitext.

Anyone an idea what a better approach would be? You can either reply here,
or write out your idea's on the discussion page [2].

[0] http://www.mediawiki.org/wiki/Extension:Maps
[1] http://mapping.referata.com/wiki/Help:Marker_data
[2] http://mapping.referata.com/wiki/Help_talk:Marker_data

Cheers

--
Jeroen De Dauw
* http://blog.bn2vs.com
* http://wiki.bn2vs.com
Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69
66 65!
--
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Maps and Semantic Maps 0.3 released

[jeroen De Dauw]

Hey,

Both the 0.3 version for Maps [0] and Semantic Maps [1]
have been released. This new release features a lot of new features
(esp. in Maps), under the hood improvements and some bug fixes. You can
find the list of changes on the extensions version history pages [2,
3]. The documentation of both extensions has also been given a big
overhaul, and should now be more comprehensive and complete.

You
are recommended to upgrade as soon as possible. This also applies for
people still using Semantic Google Maps, Google Geocoder or Semantic
Layers, which have been replaced by Maps and Semantic Maps.

[0] http://www.mediawiki.org/wiki/Extension:Maps#Description
[1]http://www.mediawiki.org/wiki/Extension:Semantic_Maps#Description
[2]http://www.mediawiki.org/wiki/Extension:Maps/Version_history#Maps_0.3
[3]http://www.mediawiki.org/wiki/Extension:Semantic_Maps/Version_history#Semantic_Maps_0.3
 
Cheers,
Jeroen De Dauw

 
Forum: code.bn2vs.com
Blog: blog.bn2vs.com

Skype: rts.bn.vs  ; Xfire: bn2vs

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!


  
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Maps-l] How should I generate static OSM maps for Wikimedia with the SlippyMap extension?

[Brion Vibber]

Ævar Arnfjörð Bjarmason wrote:
 On Wed, Jul 15, 2009 at 12:42 AM, Brion Vibberbr...@wikimedia.org wrote:
 Static maps of arbitrary size presumably have much the same problem here as 
 the map tile images. How is it handled there?
 
 The same way I want to do static map generation. Just put an arbitrary
 expiry time on it  serve it to the client.

Handy that!

 It might be good to use a Google Maps Static-like model here; the
 MediaWiki end can just make itself an img and stick all the relevant
 info onto the URL, calling out to the static map server.
 
 That's a very good idea, but I'd been assuming that I wouldn't be able
 to do that -- that each apache server was supposed to do things like
 EasyTimeline generation / image rescaling and likewise static map
 generation on its own  write it to the shared image NFS.
 
 But just being able to call out to an existing server makes things a
 whole lot easier.

Yep... this way is usually easier to manage for us, and also helps to 
isolate services for performance and security reasons. If the map 
rendering goes crazy and uses ten bajillion gigs of RAM and disk space, 
we don't want that taking down the site. :) If it's isolated and nothing 
depends on synchronous result returns, then you just don't get new maps 
until it's fixed.

For things like the PDF rendering where we need to be able to return 
data through the main web servers, isolation is still better -- we just 
need a timeout on fetches to make sure we don't get a million reqs stuck 
if the service hangs.

 This also means that we can set up the Wikimedia Deutschland servers
 to do tile rendering and then easily test it on a big wiki (like
 dewiki) by just enabling the SlippyMap extension which won't do
 anything more fancy than point static/tile URLs to the external
 service.
 
 So yay!

:D

 Either storing it on local disk there or simply leaving it to be cached by 
 upper-level squids
 
 Throwing it at the squids and making it their problem would be simpler
 for *me* at least.

Hehehe...

-- brion

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Maps-l] How should I generate static OSM maps for Wikimedia with the SlippyMap extension?

[Brion Vibber]

I wrote:
 For things like the PDF rendering where we need to be able to return 
 data through the main web servers, isolation is still better -- we just 
 need a timeout on fetches to make sure we don't get a million reqs stuck 
 if the service hangs.

Funny story: the first prototype of our Lucene search server went live 
around Christmas 2004 and immediately hung the whole site thanks to an 
overloaded server and an incredibly long default timeout for HTTP 
fetches from PHP. :)

Ahh, those heady early cowboy days...

-- brion

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Maps-l] How should I generate static OSM maps for Wikimedia with the SlippyMap extension?

[Ævar Arnfjörð Bjarmason]

On Wed, Jul 15, 2009 at 12:42 AM, Brion Vibberbr...@wikimedia.org wrote:
 Ævar Arnfjörð Bjarmason wrote:
 Hello there, long time no see:)

 In the last few days I've been working on the project of getting
 OpenStreetMap onto Wikimedia as outlined here:

 Woohoo!

 Anyway, one thing standing between us and world domination is
 rendering those static maps, I'm going to implement this but first I'd
 like to get comments on *how* we'd like to do it, so I've written a
 plan for doing it:

     http://www.mediawiki.org/wiki/Extension:SlippyMap/Static_map_generation

 I added a couple quickie notes on the talk page...

Ah, thanks, to reply to this:

 Static maps of arbitrary size presumably have much the same problem here as 
 the map tile images. How is it handled there?

The same way I want to do static map generation. Just put an arbitrary
expiry time on it  serve it to the client.

 It might be good to use a Google Maps Static-like model here; the
 MediaWiki end can just make itself an img and stick all the relevant
 info onto the URL, calling out to the static map server.

That's a very good idea, but I'd been assuming that I wouldn't be able
to do that -- that each apache server was supposed to do things like
EasyTimeline generation / image rescaling and likewise static map
generation on its own  write it to the shared image NFS.

But just being able to call out to an existing server makes things a
whole lot easier.

Then we can just run dedicated rendering machines with the apaches
being dumb about all this crazy map stuff.

This also means that we can set up the Wikimedia Deutschland servers
to do tile rendering and then easily test it on a big wiki (like
dewiki) by just enabling the SlippyMap extension which won't do
anything more fancy than point static/tile URLs to the external
service.

So yay!

 Either storing it on local disk there or simply leaving it to be cached by 
 upper-level squids

Throwing it at the squids and making it their problem would be simpler
for *me* at least.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l