[OSM-dev] [OSM] Informations about osmarender for Google SoC

[Mario]

Hi Sven!

First of all thank you for your precious informations.

> If my memory doesn't play tricks on me that was me who suggested this 
> Tool on the GSoC wiki-page. So I'm very pleased by the enthusiasm you 
> put into this idea.

I like it for sure! :)

> My dream is that any clerk whose computer-skills are 
> limited to MS Word and Outlook is able to render her boss a map of, say, 
> Europe with the company-logo displayed for every branch and nothing else 
> except ,coastlines, national boundaries and cities with more than 
> population=500 000.

This is exactly what I would like aiming to, and I'm happy I could get 
on the same page...
Well... at least starting to aim, with that sort of bottom-up (building 
the code that handles the XML files) and top-down (mocking up the GUI 
and eventually build a skeleton) mixed design strategy.

> So I'd favour a Web-app from the very 
> beginning since this could (in the early stages) also serve A)-users by 
> offering a downloadable rules-file. Some interaction with the export tab 
> would also be easier in that case.

This is one of the options, and I will include it in my application for 
sure. The only issue is that if it were to be integrated with the 
existing web app, it has to be written in Ruby, and I've never coded 
Ruby before (even if I read various articles and howtos just to get 
aware of it). This is not an issue to me (as far as I can (and willing 
to!) learn Python for Inkscape, I could learn instead Ruby before SoC 
coding part starts..), but I don't know if the community/mentor are 
agree for my application to be accepted. I think it's not a good idea to 
propose to encode that in PHP or as a Java servlet (languages, as I've 
said, which I've already learned), because it would lead IMHO in a 
language-mess, more difficult to mantain.
If someone can, please give me some hints about this problem.

>> 5) Node names or way names (or groups) can be selected through a kind of
>> pull down menu which filters the content of the original OSM file.
> 
> Pulldown-menues and combo-boxes are just what I had in mind. Don't 
> forget some sort of color-picker.

Maybe some kind of text/image mixing with the combobox. I dream about an 
evolution giving the preview of that node and something around (if 
useful and possible, but I always think that everything is possible, 
just a matter of time ;))).

> When allowing the user to 'upload' his own icons other formats than svg 
> should be accepted, like png etc. Think of the clerk, she won't know 
> either SVG nor the format of the logo-file she has on her disk...

I think this is only limited by original file size and algorithms for 
image resizing (which could lead in great use of memory), especially if 
this task has to be accomplished concurrencially by a server. And 
obviously by format licensing.. and formats accepted by the used 
conversion library. And perhaps with other things, which I'm not able to 
see now.

> That could be an additional module to allow users to upload their 
> rule-files to the OSM-Server (along with some description and maybe an 
> PNG-sample) to share them with other users.

This is just a great idea! It could fit with a client-side application 
(with an uploading to server method) and server-side both.

>> Can you please explain better this approach? I'm figuring a "classic"
>> web app, with some AJAX to let the browser render any modified SVG file
>> the WYSIWYG way, and some javascript (or a Java servlet) to modify
>> styles/rules. Is this correct?
> 
> IMHO that's correct. But only when there's a color-picker ;-)

As far as I can understand.. you like color-pickers very much ;) But I 
do too :) (only for usability.. Personally, I love the hex way :))

> I'm aware that most of 
> the above can't be achieved within one SoC.

This is unfortunately true. But the future GUI could benefit much from a 
fully functional, well-documented and unit-tested core (remember 
Frederik's idea about a highly-parametrized CSS) and from a 
"pencils-down" usability brainstorming and study. This GUI would be very 
important to the project as a whole, easy-customizing free maps are a 
must-have and could lead to unpredictable importance (I think about, for 
example, Openstreetsmap's wikiproject...). Beyond all the techies this 
is what I'm getting enthusiasmed for.

> But when you need a user's opinion 
> about usability I'll be glad to help.

Thank you for your kind reply and for your disposability!

Regards,
Mario