User talk:Rac98

staticmaplite

Hello, I see that [[1]] is listed as "active and looking for co-maintainer(s)" - I have used your code with great success, for generating static maps on a self-hosted server; I have also added some features which I needed - HTTP caching and zoom-to-markers (see [[2]] ). I would be interesting in co-maintaining this project; what do you think?

Piskvor (talk) 13:50, 29 January 2014 (UTC)

The code as of now

I have added more comments to the code; here's the executive summary:

- class definition and invocation is now separate (so that including the class doesn't automatically launch it)

- constuctor now takes an (optional) array of configuration options (see staticmap.php)

- constructor throws exception if required libraries are not present (curl,gd)

- removed the tileservers which are no longer functional (osmarender, cycle)

- added in-browser caching through HTTP headers and conditional validation (sendHeader() and showMap())

- added zoom-to-markers: when `center` parameter is omitted, getCenterFromMarkers() will select a zoom level and centerpoint at which all the markers are visible - e.g. here is a [manually selected] center and zoom, and here is the [automatically selected] center and zoom for the same set of markers

- added: outgoing HTTP requests have a (configurable) User-Agent

- added: can now return JPEGs and GIFs in addition to the default PNG

- minor change in marker positioning (two markers, one just north of another, used to overlap unpredictably; now the southernmost one is in front)

- minor cURL timeout tweak

As far as Wizzard is concerned:

- updated code to work with current OpenLayers (there was a breaking change, replacing OpenLayers.Control.MouseDefaults() with OpenLayers.Control.Navigation())

- removed non-functional tileservers

- added a checkbox for the zoom-to-markers feature

- added a button for current geolocation (not used by generator - only moves the wizzard's map coordinates and zoom level)

I have also added the note "staticMapLiteEx developed for ReKola.cz", both to the example page and the Wizzard; I can remove this in case you wouldn't like it.

Best regards, Piskvor (talk) 14:03, 30 January 2014 (UTC)

Future plans

As to "what am I planning to implement" - I am looking at using the script as a GMaps Static replacement (which is the reason I started tinkering with it, and all of the following would scratch some of my itches); for starters:

- I'm looking at the marker options - colors, size, letters - and the ways they can be specified: GMaps allows entering multiple sets of markers - `?markers=color:blue|foo,bar|baz,bar&markers=color:red|xyzzy,foo|foo,baz` - from which PHP will only take the last marker into $_GET. So I'll probably need to pre-parse the request string, and probably pass markers in through a method, after construction (working on this)

- Another thing is the "scale" feature, which should be relatively easy (a size=400x300&scale=2 request returns a 800x600px image, which is a 400x300 scaled 2x)

- viewport focusing for auto-zoom ("also keep this point inside, but don't mark it on the map") - something of an "invisible marker"

Something which I call "where am I, relative to the viewport?" - a pointer at the edge of the map, pointing outwards to the actual marker, which is off-screen

What is your opinion on these, and do you have some features of your own which you'd like to see in staticmap?

Best regards, Piskvor (talk) 18:37, 30 January 2014 (UTC)

What next?

I'm not planning at matching Google Maps feature-for-feature; as you wrote, the project has *lite* in its name for a reason. I think we *shouldn't* be even trying to look&feel like GM; what I'm looking at is the use case "I have been using GMaps Static until now, and am looking for an alternative to give me similar *functionality* with minimal transition effort." I'd keep to the 80/20 rule - most people aren't using the advanced stuff like encoded polylines and style layers; providing the markers (and simple lines, perhaps, sometime in the future), would be sufficient.

As for the style of development - I must admit that I don't like the SF+SVN combination too much, but let's not fragment it and keep the mainline code there; if you don't have time yourself, I can merge the changes from git(hub).

That said, I believe that the deployed version should match the state of the code (on SF), yes. I've already bumped the version number to 0.04 in my changes - I consider the changes to be significant to warrant an increase. The new code is not significantly slower than the original.

Now, IDK if you want to deploy it yourself - should be just a matter of svn up :) there are no breaking changes that I'm aware of, and previous features should continue working.

Best regards, Piskvor (talk) 16:50, 5 February 2014 (UTC)