Hello!
On Thu, 06 May 2010 22:15:19 +0200, Dane Springmeyer <[email protected]>
wrote:
In addition, I'd also like to see you document and share a little more
about how you think that the Google Apis clickable labels work.
As far as I've investigated it so far every click on the map sends a
request to Google's servers which contains the point the user clicked at
and returns information about the feature at this position (if any).
But they also send a list of all visible features, but without details.
I only looked at network transfers and I'd like to avoid looking at their
code as this might create potential legal issues.
One thing I've seen is that google places labels not always above a point
but sometimes also to the right or left.
Here is an example:
http://maps.google.com/maps?f=q&source=s_q&hl=en&sll=37.0625,-95.677068&sspn=36.452734,73.388672&ie=UTF8&ll=52.517226,13.396111&spn=0.006842,0.017917&z=16
I'll try to find such an area on
the map. It would provide a good example of what this project is about.
It will also be good to give thought to how to expose these features in
Mapnik's XML stylesheets, so that users can easily decide which layers
(or perhaps even styles, if more than style pulls from a layer), are
clickable, and with what metadata.
I'll try to find a good solution for this, but this can be defined later,
when the other code is working and I have more experience how it might be
used.
Layer's currently have a queryable="<bool>" parameter which is used to
determine whether the feature should be able to be queried from a WMS
server that supports GetFeatureInfo. Something similiar to that
parameter may be in order.
I'll have a look at GetFeatureInfo.
yes, yes..., or shift a line to the side
(https://trac.mapnik.org/ticket/180) (though most utility will relate to
point placement I assume).
There are some line feature which might be worth considering (e.g. famous
bridges, etc.)
At the point during processing at which an object (line, polygon, text)
is actually output to the final image the geometry data is captured
together with an user definable object property (object ID, street
name, …) and written to a metadata section. For more complex features
post processing might be required that combines features to reduce the
amount of data.
Yes, so right now I see this happening inside agg_renderer.cpp or
cairo_renderer.cpp + placement_finder.cpp. Perhaps after getting
metadata collection working within the actual renderer code, you could
think about ways to make it more generic, perhaps through subclassing.
Involving Artem Pavlenko in the question of how existing renderers might
be extended/designed with this flexibility in mind will be important.
I try to understand the code a bit and then I'll discuss the way how to
code this.
- The project idea page in the wiki lists EXIF as a possible output
format. This might be well suited because all data is contained in one
file, but it's hard to read EXIF data in JavaScript which is the main
platform for clickable maps. I was able to find only one JavaScript
EXIF implementation and it doesn't work in all browsers.
Yes, great ideas. They certainly all have benefits. I know the
Javascript EXIF may not be compatible with IE, but is could be very
slick in the future as support came online (I presume browsers
supporting Canvas would also support JS libs that can parse EXIF
directly from the image?)
I haven't found such a lib yet. The autor of the only library I know of
writes "So, there are two parts to the problem. First step is to get
access to the raw binary data of the JPEG. Now, while it's easy to get to
the pixel data using canvas, we don't get any of the data around the
actual image, and that's where the interesting parts are hidden."
(http://blog.nihilogic.dk/2008/05/reading-exif-data-with-javascript.html)
Of course the implementation and output formats are open to suggestions.
Yes. My tendency would be to start with sqlite, as a balance of
efficiently and portability, but I am open to suggestions. Something
that was file based and could be directly parsed by OpenLayers would
also be very useful....
I think file based output would be the easiest solution because it can
be read by any text editor. (This helps debugging). When this works more
formats can be added.
Hermann
P.S.: Next messages will go to mapnik-devel only as this is not relevant
on the user list.
_______________________________________________
Mapnik-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/mapnik-users
