maposmatic-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Maposmatic-dev] New OCitySMap version live on dev.maposmatic.org


From: Maxime Petazzoni
Subject: [Maposmatic-dev] New OCitySMap version live on dev.maposmatic.org
Date: Fri, 15 Oct 2010 09:43:42 -0700
User-agent: Mutt/1.5.20 (2009-06-14)

Hi all,

As you probably know, we had quite a few hosting issues in the past few
weeks. We finally reached a more stable situation and the MapOSMatic
service is back online, as discussed in the recent blog posts.

This also gave us the opportunity to deploy the new version of the
OCitySMap map rendering engine to the development version of MapOSMatic
on http://dev.maposmatic.org/

In a recent email to address@hidden, David Decotigny brought up
a series of issues / areas for improvements and I think it would be best
to discuss it here on the development list, which is opened to the other
people's opinions.

During the hackfest, David and myself wrote a good portion of the new
OCitySMap, and David is the one who finalized after the hackfest (while
I was busy working on the server and moving the US) the various
rendering layouts after this summer's hackfest. I think we can all thank
him for this, as it helps a great deal in feeling that this last
hackfest did indeed produce something great.


His first remark was on the new map creation wizard, saying that the
"previous" / "next" arrows to move from one step to the other were not
very intuitive. I, too, do not find them perfect, but the few
experiments I've made on the wizard while working on it after Thomas's
first draft didn't produce anything satisfactory. I'm welcoming any
other approach, maybe we're just not simply using the correct paradigm,
or the several steps could be presented in a completely different
manner, I don't know. Let's open a discussion on this with the boarder
MapOSMatic developers/contributors/users community!

On the wizard still, there are some cases where the only paper size
available is the landscape best-fit. David Anderson recently pointed out
that when this is the case, it's not worth showing the choose paper size
step at all, or at least add a message that says the chosen area
doesn't fit on any of the paper sizes we support, which would avoid
leaving the user in the void with a single-choice selection.


On i18n, David Decotigny pointed out that its implementation might be
incomplete. There are indeed a few places where some strings were
hardcoded, and we need to rework that. And a lot of new strings were
introduced, which will require our translation contributors' attention
before we consider releasing this anyway.

Another i18n bug remains in the map generation as well, where the
generation date appears in English on all the maps, regardless of their
chosen locale.


Still on the wizard, the map language selection definitely needs rework,
as it does not propose the most common language for a given country by
default because it relies on whatever order the underlying Javascript
puts them back into the list. For example for a city in France, the
first and default selection in the list is "Franca (CA)" for Catalan,
while it should be simply "French". Same goes for a whole lot of other
languages that have alternative locales.


Both David Decotigny and David Anderson also suggested that we move to
an AJAX refresh of the job status page. This would also improve our
public APIs, offering a generic job status API. Along with the map
creation API, this means people could soon offer non-web-based
MapOSMatic clients.


David Decotigny also suggested that we display the size in pixels of the
generated PNG map. I understand this could be useful, but it means yet
another database schema change. But it can be done.


So, there it is. I declare the discussions open!
Enjoy, and don't hesitate to give us your feedback on the development
version of MapOSMatic and on these issues!

- Maxime
-- 
Maxime Petazzoni <http://www.bulix.org>
 ``One by one, the penguins took away my sanity.''
Linux kernel and software developer at MontaVista Software

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]