Skip to content
Find file
Fetching contributors…
Cannot retrieve contributors at this time
1710 lines (1185 sloc) 108 KB
== to do ==
=== b1 ===
* geomap - allow service-level refresh
* geomap - loadstart, loadend events
* geomap - [bug] dragBbox doesn't include the bbox property in the shape
* geomap - allow append to take an array of shapes
* geomap - allow remove to take an array of shapes
* geomap - add argument to refresh to force reload of images (in case of dynamic data)
* geomap - zoomMax option
** accept null first argument and coordinate or bbox second argument
* geo - include method for bbox
* geomap - test changing shingled service URL to get updated images (in case of dynamic data)
* geomap - [bug] there's an extra service.refresh call after a non-mousedown touchmove after a refresh
** most noticeable on shingled services
* geomap - [bug] tiled services with pixelSizes set do not render zoom level 0
* geomap - [bug] errors when setting src to empty string
** "When I added services for my graphics layers with src set to an empty string I got very weird results -- I was seeing the single image from my inset map repeated over and over. I had to set it to a function that returns an empty string for it to work."
** possibly an object reference error when multiple maps are created
* geomap - [bug] if panning is false, mode is draw*, and user attempts to pan, the drawing begins (or another point is added) on the touchstop point
** a failed pan shouldn't add a point to drawCoords
* geomap - iPad 2 - [bug] pointAlong doesn't take last point into account in all browsers
** cannot reproduce; possibly axisLayout image only
* geomap - ie - [bug] ie highlights entire map div during shift-zoom
** possibly only when axisLayout is image
* geomap - [bug] iPad 2 measureLength puts current length on second to last coord instead of last coord
* geomap - [bug] first use of mouse/touch in any mode moves map by one pixel on mousedown/touch
** possibly only when axisLayout is image
* geomap - [bug] after one finger is removed, stop processing as if multitouch is still on
* geomap - [bug] multiples of the same event trigger after creating more than one map on the same div, even after destroy
** destroy should unbind all geomap events
* geomap - verify that multiple maps work on the same page
* geomap - [bug] exception when calling destroy on uninitialized div
* geomap - do not interactiveScale non-tiled maps out past pixelSizeMax
** pixelSizeMax calculated by zoomMax on non-tiled maps
* expose jQuery Geo as an AMD module so asynchronous loaders like RequireJS and curl.js can use it
* geomap - [bug] when a singled image hasn't loaded after pan and you double click on empty space, the zoomed bbox seems wrong
* cdn - test cache headers with before release
=== examples ===
* examples - jQuery Mobile
* examples - MBCR:
* examples - drag shapes
* examples - ie7 - [bug] floating info div doesn't show up, inputs are alone and on the left
* examples - redo the jVectorMap demo page using jQuery Geo
* examples - make OSM editing simple
** ( found via )
* examples - geomap resize method
* examples - Codecademy course
* examples - SVG & other neat elements/media in labels
* examples - continent puzzle
=== future ===
* geomap - don't repeat attr text if the same as one previously added
* docs - geomap - zoomMin, zoomMax on service object
* geomap - zoomMin, zoomMax on service object
* geomap - remove this-style state properties
* geomap - add delegate handler for image load instead of one load handler per image
* geomap - remove "px" from .css calls
* geo - use Array.push instead of $.merge where needed
* docs - upgrade to jQuery Mobile 1.1.0
* docs - non-mobile version via adaptive check
* geomap - [bug] changing services array (without changing all services) after initialization fails
* geomap - create _defaultState object, use for widget-local _widgetState property, reinit _widgetState on _createWidget
* geographics - draw to img elements to include in interactiveTransform
* geographics - try removing the blit canvas from the DOM, i.e., don't attach
* geomap - maybe throw an error when setting center to an invalid object, such as the first number in a coordinate array: coordinates[ 0 ] <== wrong!
** oddly, iPod Touch 4 (iOS 4) is fine
** might be related to the jQuery UI bug I found
* geomap - implement service-level shape redrawing during interactive movement
* geomap - use CSS transition or transform for smoother tiling
* geomap - don't request tiles that > max possible y for scale
* docs - geomap - view.service.row & view.service.column to string multiple services together or repeat horizontal tiles
* geomap - Firefox - [bug] inertial pan is choppy post touchstop
** post inertial pan rewrite
* docs - geomap - describe "graphic service" as shingled with src set to empty string or null
* docs - warn users about potential CSS/JavaScript issues relating to generated elements
** ul, li, div, span, img
* geographics - draw all labels to a string or document fragment and append to DOM once
* geomap - compile shingled & tiled string src templates for re-use
** be sure their template names are unique so they don't overwrite each other
* geomap - don't redraw graphics if the map doesn't move during pan
* geomap - replace data-geo attributes with classes
* geomap - cache label coordinates (the labelPixel cannot be cached, it will change each refresh)
* geomap - rotate label based on segment
* geomap - use pointer-events: none where appropriate
* docs - geomap - allow template for label argument to append
* geomap - allow template for label argument to append
* docs - geomap - allow template for properties on style argument to append
* geomap - allow template for properties on style argument to append
* docs - geomap - shapeLabel property
** template for labels for all shapes added via append
* geomap - shapeLabel property
* docs - geomap - allow template for properties on shapeStyle option
* geomap - allow template for properties on shapeStyle option
* geomap - better integrate resize with interactiveTransform
* geomap - determine if moz-transform improves speed in Firefox
* geomap - [bug] once we detect a pan, disable the ability to go to multitouch
* geomap - [bug] verify label clamping is correct in axisLayout=image maps
* docs - geomap - pass the service id (if there is one) to the src callback as a view property
* geomap - pass the service id (if there is one) to the src callback as a view property
* docs - geomap - support dynamic map services that only work in geodetic coordinates (sr=4326)?
** can be done with src function that uses $.geo.toGeodetic?
* geomap - support dynamic map services that only work in geodetic coordinates (sr=4326)?
* docs - geomap - pan events (pattern after HTML5 drag)
** can cancel with preventDefault
* docs - geomap - zoom events (pattern after HTML5 drag)
** can cancel with preventDefault
* docs - geomap - support two-finger vertical slide as zoom on mobile devices
* geomap - create own .position function b/c $.position is doing too much
** we don't have to worry about border or margin, all elements are within map div
* geomap - pan events (pattern after HTML5 drag)
* geomap - zoom events (pattern after HTML5 drag)
* geomap - test jQuery widget call chaining when setting option values
* geomap - when scroll is zoom, attempt to not zoom while user is scrolling the page anyway
* docs - geomap - document the correct way to add/change a service after init
* geomap - unbind keydown handler on destroy, it's on the document
* geomap - use requestAnimationFrame instead of setTimeout when waiting to move the map during intractiveTransform
* docs - $.geo.WKT object
* geo - $.geo.WKT object
* geomap - panning cursor (closed hand, for when user is actually panning)
* geomap - completely original cursor set for pan, zoom, draw, etc.
* docs - geomap - replace method
* geomap - replace method
* geomap - draw shapes to img and integrate with interactiveTransform
* docs & examples - settle on the word "option" in all text (instead of property) to match widget function
* docs - make all map examples live
* docs - explain the 96px scale bar, why 96?
* docs - write a full page about GeoJSON and what each object type is to $.geo
* docs - geomap - allow name as service object property
** if a service has a name property, it will maintain a hidden input with the given name
* docs - geo - support up to GeometryCollection in distance
* geo - support up to GeometryCollection in distance
* docs - geo - support up to GeometryCollection in contains
* geo - support up to GeometryCollection in contains
* docs - geo - support up to GeometryCollection in centroid
* geo - support up to GeometryCollection in centroid
* geomap - stop using $.data to store bbox since it's only used for drawing; store on _graphicShapes instead
* geomap - show a drawPoint style while the mouse is down, hide if toolPan or dbltap scale
* geomap - audit allocations and reduce garbage
** see
* geomap - re-use services that have the same id as existing services
* geomap - deep extend existing service objects when services property is set
* geomap - cache point bbox if $.geo.proj is not null?
* geomap - spatially index shapes when a tilingScheme is in place
* geomap - internal - add _getVisibleTiles method and use it in tiled service and shapes spatial index
* geomap - remove wheel plugin and use built-in mousewheel event
* geomap - test how the comma selector works with the find method
* geomap - compile service src templates, refresh when services changes
* code - prefer $.data over $
* docs - internal - explain what projection is and which one we use by default (3395) and maybe why we call it web mercator & why we can't get to +/- 90 lat
* docs - internal - document how geomap draws shapes, the geomapgraphics widget and the reason shapeStyle is a method
* docs - demo - location based notes/to do list
* geomap - find should check labels first
* geo - geometry - implement JTS note: "The centroid is equal to the centroid of the set of component Geometries of highest dimension (since the lower-dimension geometries contribute zero "weight" to the centroid)"
* geo - all bbox operations should be done in non-geodetic coordinates for accuracy
* geo - support bbox in distance ( fix geomap.find )
* geomap - perf test putting all containers that need to move with panning in a single super-container
* docs - geomap - multiple labels
* geomap - multiple labels
* docs/geomap - store WKT input for each service
* geographics - rename the generated style properties to something simple or get better control over closure compiler
* geomap - document and implement find's callback syntax
* geomap - custering demo/support
* proj - take scale factor into account when calculating distance in web mercator
* geographics - disable fill by setting style.fill to "" & stroke by style.stroke to ""
* graphics - See Modernizr for comment on BB Storm & canvas detection
* geographics - document graphics widget
* geographics - support border, padding, and margin
* geographics - undo manual outer div style changes
* geomap - store a copy of shapes as WKT in a hidden input
* geomap - only update WKT copy if shape is appended with refresh argument set to true
* geomap - find - [maybe] after flatten, check more cached bboxes for non-Point geometrie
* docs - geomap - support TMS
* geomap - support TMS
* docs - geomap - toDataURL method
* geomap - toDataURL method
* docs - geo - $.geo.guessLocation function
* geo - $.geo.guessLocation function
* docs - services - document the plugin architecture
* docs - geomap - drawPush function
** in the drawing modes, this function starts drawing or adds a point into the already-started shape at the given coordinate
** immediately triggers the shape event if mode is drawPoint
* geomap - drawPush function
* docs - geomap - drawPop function
** in the drawing modes, this function ends drawing or removes a point into the already-started shape at the given coordinate
* geomap - drawPop function
* docs - geomap - drawStop function
** in the drawing modes, this function ends drawing and triggers the shape event with whatever coordinates have already been added to the shape
* geomap - drawStop
* geomap - use profiling to improve pan performance
* geo - potentially add address cracking
I've been away for almost two weeks. Time to finish b1.
This is where I left off. I'm also considering zoomMin and zoomMax on service objects but that's not until later if needed.
The new origin stuff appears to work better. I'm going to run through the other examples & see if I'm ready for a build.
Chrome's screen tearing is really bad. I'm going to try to disable 3d transform in Chrome. Maybe it's just my laptop, Chrome is doing the tearing even without translateZ. I'm reverting the changes for that test.
I'm getting a bbox event after a single tap.
I need to only call this if: a) it's already been called once (to keep it going) & b) we actually change centerInteractive or pixelSizeInteractive.
The programatic changes are going to be a part of this, too. I need a way to turn on trigger during setInteractiveTimemout.
I updated all the programatic calls to use the new system with the ability to say not to trigger. I will need to test these but for now, I do think I'm finally ready to merge.
I merged the interactive rewrite into b1. There are bugs that I will have to work through before this becomes beta.
===initial zoom===
No matter what your initial zoom is, you can see the map at zoom 0 before the new tiles show up. That makes sense given the changes I've made.
ok, the area that handles init options checks to see if the widget has been created before heading into intractiveTransform mode.
I *know* ie8 support is broken. I haven't even tried it yet. We will keep supporting that browser, though.
I'm ignoring rogue mouseup events now. Hopefully, that will clean resize up a bit on Chrome & Firefox.
Seems to work like it did before. I'm going to increase the frequency (decrease the timeout) of the resize check. In the future, I want the resize in two parts, one to move stuff around in real time/animationFrame time, another to perform the final refresh. Maybe move the latter back up to 500ms? Maybe not.
67ms is too soon, Chrome flickers. I'm bumping it back up to 500ms for now.
This should really be part of the new interactiveTransform code. At least, moving the images around and waiting for the final setCenterAndZoom. The issue I'm seeing with tiled now is that if I pan and the resize before the new tiles come in, the map jumps from the interactive to the final center. Same with shingled.
For now, I think I may be done enough with this to merge back into the main project. That's a lie. I disabled a bunch of stuff before doing this, like marquee zoom. Any of the immediate mode changes.
I'm going to try to tie these into the new interactiveTransform.
The last obvious thing broken is moving the draw points during interactiveTransform.
shapesContainer is no longer part of panContainer which is now only draw or measure layers.
Scratch that, I'm not going to move the original panContainer. I need to include the draw and measure coordinates in the new interactiveTransform stuff as well.
That works ok, I think. I might change it later depending on how was shape drawing to img elements goes.
I still need to test scale changes with drawing but I have a feeling it's fine. Took the code from pinch zoom.
I forgot, tiled still needs some of the origin fixes I put into shingled.
Chrome & Firefox trigger a rogue mouseup event when maximizing the window. I don't think that's right but I suppose I have to handle it. But, for some reason, geomap in Firefox doesn't trigger the refresh.
Much better now! Two things I was missing: 1) I needed to base calculation on the original map origin of the scale container & 2) the position is now %-based, like tiled.
I don't think there's a need for this any more so I removed it. I had better make sure :) Oh, right. It was for opacity. We don't want to layer semi-transparent images.
The code's not here. I see where I set keepAlive but can't find where I delete the images. This may be a regression from, like a2.
I probably had it chained to a line I deleted.
Oooh, I didn't need it anymore when I added the concept of a pan container way back. Since I no longer have pan containers, I have to add keepAlive back.
Yep, I had to add it back with the pan/zoom rewrite.
For resize, I should be able to just resize each scale container. Everything else is %-based.
I need to finish the rewrite by making sure graphic overlays move correctly.
I might cheap out and hide the graphics for the b1 release. The geographics widget needs its own interactiveTransform method.
Do I need my blit canvas to be part of the document? I hope now, will remove it soon.
I was originally moving all the servicesContainer for all services INSIDE the loop where I was moving all services.
Also, _$servicesShapesContainer did not include the draw or primary shapes containers. I wonder if that was on purpose. It should not include the draw container because those shapes change during any change in the mouse or map.
shapesContainers will eventually need the transform, but again, maybe not now. For now, I'm hiding the drawn shapes during interactiveTransform.
There's still a jumpiness issue when you catch it just before/during refresh. Old tiles that have already been scaled pop into weird locations. Should I fix it now or continue with shapes? Probably, I should finish with shapes and then work on bugs.
===pinch zoom===
Hmm, there are issues here once I turned refresh back on.
It's with double click zoom as well, once you start panning.
A single hardware pinch zoom appears to work perfectly if you don't pan any time after the zoom. I end up in Africa or the Virgin Island a lot from MA on the iPad.
Definitely a problem with refresh. Disabling the refresh timer shows that interactiveTransform still works fine.
I'm not doing any pixelSize clamping in _setCenterAndSize. That must have originally been somewhere else. With that change, there is still the jump issue of old transformed tiles but I don't seem to end up in Africa.
===pinch jump===
I need to jump to the closest pixelSize, not the smallest. It will make this smoother...maybe in the future as well as it only affects when they zoom in just shy of the half-level mark.
I'm creating a new shingle for each pan, which is right, but not positioning it correctly after refresh.
Actually, this is a much better representation of the jump issue I'm seeing in tiled. If I fix this, I may be able to fix tiled based on it.
===data vs. parseInt===
I'm going to guess that storing a number with $.data is much faster than trying to use parseInt on current CSS values. Although, the parseInt would only happen on refresh, while the .data call will happen with every pixel move.
I have to get this started. Appears to work pretty well. What's left for beta?
===non-moving divs===
I don't think I need the transform on divs that don't move, such as the event target and content frame. I'm removing it for now.
I turned refresh back on and there's still that image repeating. I'm going to log some stuff and see what I can discover.
First step, interactiveTransform is being called on every mouse move even when the mouse isn't down, that has to stop.
Wow, I was making a new scale container every time because I had changed to using data-pixel-size but was still testing for data-pixelSize.
The duplication is now gone. You can still mess up the view if you start panning right at the right moment, just as it's about to refresh but I can live with that for now.
I suppose shingled is next.
Since tiled is pretty much ready for linking to the true refresh, I can either fix shinged now or actually implement the refresh. I suppose I should try to finish the rest of the geomap widget with tiled for now. It's not fun to be unable to refresh the map in this in-between state.
Tiled services are ready to be merged into refresh. I'm going to skip the _panEnd stuff now and just go to _panFinalize. I can add the inertial pan back later.
Calling _setCenterAndSize at the end of my timer now. Pretty fast! I'm getting weird behavior with tiles that aren't in the current view, though. And some, look like they're repeating. It all settles down after the refresh but the quarter second leading up to it there is a visible jump.
Setting the transform on the images helped iOS. Settig it on the map div itself helped Android a lot and iOS a little.
If there's anything else over the map, iOS doesn't respond very well. It doesn't let me pan (scrolling the page instead) and pinch zoom is just weird.
Out of a whim, I didn't include the jQuery UI style sheet. iOS now works like the others. I wonder what's in the style that it doesn't like. Latest version of jQuery UI (1.8.19) still has the issue. I wonder which widget does it.
Weird, if I take out the .button() calls, the demo works on iPad.
iOS works fine with fixed position. It's still the .button calls. I'm sniffing out the button calls for iOS 4-5 for now. I don't have time to figure out that issue.
I've been wanting to use better features in ie9 for a while. Let's see how this goes because with the new code, I have to drop the filter. I didn't like using filter anyway.
I cannot belive how nicely the transform scale + transform-origin work in ie9! I might investigate using them instead of the % hook on the scale container for webkit & Firefox.
_inOp gets set to true during pan.
When to have the interactive center and pixelSize match the current values? Any function where timeoutInteractive is null, likely.
I may have been moving the services' shapesContainers twice, once in _panMove and again in the service's serviceContainer.children().css call. No, the service container is the data-geo-service object. Its only children are scale containers.
I'm not going to move the scaleContainers separately during pan...oh, I have to because they will move at different velocities.
I'm attempting to add transform support for iOS. 3D CSS transforms make the images bounce around funny during scaling. At least, when I set the CSS on the scaleContainer.
In some instances, the measure tool doesn't position properly. Going to change it from a div to a span to calculate width better. The container can stay a div. Only the actual label needs to be inline.
Fixed. I'm also clamping to [0, 0] so the measure label doesn't move past the left or top of the map.
===pixel measure===
I can tell I will have to add support for axisLayout=image into the measure code. The clamping is backwards.
On bad polygon geometry (hourglass is the common example), our centroid function returns weird results. I might clamp to the bbox for now as a stopgap until I fix it for real.
That's better. Not great but not nearly as much weirdness.
Back to this. I need to disable the pan pop as well as calls to refresh.
When panning, we move the _$panContainer. It contains various top-level items (shapes/draw/measure containers). Each service moves their own content. Pan finalize resets the pan container as well as the shapes container for all services.
I'm still doing too much in touchmove.
Now caching the reference to services shapesContainers.
Where was I? :) Right, first disable all refreshing and attempt a the new interactive pan.
Not all refreshing will be disabled, the function/option calls from the developer should be honored.
Private but never called?
===no refresh===
With all _setCenterAndZoom calls commented out, the pan container still jumps back to starting position. That's expected with the current code but shouldn't happen when we're done. That jump needs to wait for the full refresh.
===b1 docs===
I got some more docs in. I need to take a small break and actually rework the pan/zoom engine.
So it begins. I think the first thing to do is create the clearable refresh time during pan/zoom and remove the duplicate refresh code in interactivePan & interactiveScale.
Google Maps requests new tiles during pan when running in Chrome on the desktop, however, the mobile website waits until the user lets go of the map.
That's what the bbox->polygon function will be called. It's in GEOS. Their docs say: Polygonizes a set of Geometries which contain linework that represents the edges of a planar graph.
While that's supposed to be only for linework, e.g., a LineString to Polygon, I think it's fine to extend that to bbox. It's not called polygonize in JTS, there's a Polygonizer class and a getPolygons method. I'll simplify that, too.
I changed the shape value to dragBbox so I can use it in the code a little more smoothly (choosing cursors, actually switching the mode).
I gave my talk, went ok. Gotta get back to docs.
This mode should operate even if pannable is set to false. There's a test in the code where I have to special case that out.
I'm coding at foss4g!
Deferred demo is done.
### markdown
The new markdown file looks nice!
### docs
Time to document the last feature that are going into b1. Actually, I want to lint the last file, tiled.js.
### Deferred context
The last lint issue is that I shouldn't create functions in a loop. That's done when the user returns a Deferred object as the tiled service's src property. The function calls _loadImage on the service object but needs more than the url, which is all the Deferred done call gives it. How do I get the rest, such as $img, pixelSize, etc. $.proxy? But isn't that creating a function anyway, just one that lint can't see? Yes, it does. Maybe I can put the data on the Deferred object itself. I don't see why not.
I haven't written in a while. Checking out grunt now.
Wow, that was cool. jQuery Geo now compiles with Grunt and I also have a jQuery plugin package file!
===graphic holes===
With canvas, I have better control of drawing polygons with holes. It's pretty nice. I can't wait to get into WebGL.
The code already worked the way I wanted! No .geo-label div is created if you don't at least provide an empty string label.
Need to implement the * selector. That was easy. $.isPlainObject thankfully returns false on strings.
===unloaded image===
It appears that when you pan starting on an area that has an unloaded image, i.e., empty space, this._center gets set to string values. Checking on this now.
===shingled 0===
To prohibit shingled maps from zooming out past 0, I had to change quite a bit of code. I now have getZoom & getPixelSize methods that will work regardless of tilingScheme. I'm also calculating pixelSizeMax when bboxMax changes and making sure the non-tiled zoom doesn't go less than 0 in two spots. That seems to do the trick.
===service-level shape refresh===
Shapes on services draw twice, heh. That was a tough one. Turns out, when I create the service-level geomap widgets, I wasn't setting _graphicShapes to a new array before passing the (this) object to the widget factory. All services were sharing the same _graphicShapes reference.
===current services===
I need to make sure their style property is always full, that's the point of having an internal copy. This means I have to fill in visibility & opacity when I create the services based on defaults.
=== service style===
visibility: "visible",
opacity: 1
}, style)
That returns what you would expect if style is undfined.
===str src===
I can't mod index in the template. I feel that there is a way, but it's not there yet.
This needs to be updated, it doesn't work with jQuery 1.7.
Right, this._options does equal this.options but only because the latter must be called so and we can minify the former for internal use.
I seem to be able to detect geodetic coordinates ok. I'm switching all of the $.geo functions to use it. So far, so good.
They look cool, but I don't think this project is ready for transitions, they have some unexpected side-effects. I would like to rewrite the interactive portion anyway.
There's a bug with shingled services if I call destroy and try to re-create.
Changing the services option will destroy all service-level shapes. I'm not sure what to do about that. Eventually, I will re-use serviceContainers (and service-geomaps) based on the new services array coming in but I currently don't do that.
Finally, to get rid of proj. The point is, you should be able to use projected coordinates even when $.geo.proj is not null.
The same geodetic test applies to both bbox & coords because the first two elements of either are the x and y of some number. Nice!
===shapes zoom===
Service-level shapes don't refresh while zooming and it's not going to be easy at the moment. All I can do is call geomap("refresh") on the serviceContainer which, since they're just service pseduo-map widgets, will only refresh the shapes. The problem is they don't have access to the in-between state of the zoom so the shapes don't draw correctly. I will fix this later when I re-invent the pan/zoom code for beta. For now, service-level shapes will not draw during interactive zoom.
However, it's good to have an idea of how the new system will need to work. Each service-map widget will check the _interactiveCenter & _interactivePixelSize values to draw shapes in proper positions.
This widget needs some updates. For now, I'm just going to add the resize function.
Note, with canvas, you don't need to set size CSS at all. The canvas is, by default, inline-block with width and height based on the html element attributes. Also, as is shown in this fiddle, changing the runtime width & height properties of the canvas element does clear the canvas:
===service-level shapes===
Where was I before I stopped to add Deferred & fix bugs? Right. The service-level geomap widgets should now initialize their own shapesContainer.
resize is a method on the service object because shingled need to stretch the current image.
I need to finally add resize to geographics.
find will have to query and include service level shapes.
This will be simpler if I allow services to get to the private map variables (similar to how I allow the service object to do it?). No, probably during create.
Can you have protected properties in a jQuery UI widget? I would like to be able to pass a reference to the map during create...I could also use .data. That worked fine. I now have this._map which will be the same as this for the map object and a reference to the map object for services. Nice! On parts that need to work the same between maps and services, (such as _refreshShapes), I can just call this._map.x and it will be correct.
This should be fine for services.
The src function will be allowed to return a Deferred (or Promise) object. If it does, geomap will wait for the done or fail events. The src function will call resolve or fail.
===service shapes===
The opacity method might have to stay as a service method because it must directly manipulate image elements in some cases. However, the toggle method can operate on the new service container.
===init services===
So, the jQuery UI widget factory udpates non-array options fine, i.e., when I get into the _create method, this.options has whatever the user supplied merged in with the default options. However, array options are not copied so any changes to the initial service option are not maintained.
Not true, but it does unfortunately merge the first user supplied service with the default service, osm.
I forget why I have _options and options. They are supposed to be internal vs exteternal but they are equal references.
What's next for a4? static mode.
===static mode===
This shouldn't be too hard. Currently, any non-defined mode string will act close to static. That's different from how I want it to work. The mode "static" should be static and undefined modes should act like pan for now.
The switch appears to have gone well. I can set the mode to "23" and it acts like it's in pan. That's a feature I will define more fully later and document before it's official.
Time to merge labels into geographics. This is a huge step toward service-level shapes. I should be able to find all $labelsContainer references and move them into sections of geographics.
Now that labelsContainer is part of shapesContainer, the next step is to put shapesContainer under a serviceContainer (which is inside servicesContainer). Got that?
===service-level shapes===
Here we go! Each serviceContainer has a div that contains all the images. The geographics widget will be a sibling of that.
I may need a new container :/ the extra div was the tiled service's scale container. I need a container for the service/graphics elements.
The map itself will have to manage this new container. I think the internal service objects will get this container and now append their functionality and elements to it. It will no longer have to return a new div for which the map will create a sub-geomap.
I think address parsing (cracking) will be a useful feature for geocoding to non-Google geocoders. I might want to add that to $.geo at some point. Christian has some Python code that does it already I can port.
===pinch aftermath===
Adding pinch was pretty easy. The only big issue was if a second finger touched a short time after the first. To counter, I fake as if all touch has stopped and initiate a new one. There's room to consolidate code here but I'll get to that later.
This acted funny with pinch zoom in that when the second finger hit late, a shape event got triggered at the first finger.
===draw other===
Similar issue, touchstop gets triggered after pinch zoom and a segment is added to the shape. Maybe related to calling touchstop. We get in an odd state, actually. The segment shows up but the next touch causes it to disappear and a new one appear instead.
I'm going to put this as a bug and get back to it later. There's much more actual functionality to get into alpha 4.
This is mostly ready for iOS. It's a little jumpy so I think I have to detect a second touch while the first one is down as long as they haven't started panning yet and move into pinch zoom.
If the second finger is late, we still only get the touchmove event which will work great.
I am going to coin "hold scroll" for android to counter their lack of multitouch. When the user holds the map in the same place for between .5 seconds and before the browser takes over, the user can move the touch point vertically to start zooming as if there's a scroll wheel.
I was going to have "expand zoom" (coined by Laura) where it works similar to "hold scroll" but instead of acting like a scroll wheel, it acted like the bbox was expanding from the hold position. In effect, a zoom in only fake pinch zoom. However, I like the zoom in/out ability of the fake wheel better. This will also work on iOS, I think and even desktop.
===web workers===
I eventually want the $.geo functions to allow the browser to use web workers but they'll have to be in a javascript file. Hopefully, I can use data URIs.
I could always grab the worker js from the CDN but that would require internet access. What if it's all an internal site, like for government. Or, graphics only that doesn't need servers.
I can use data URIs but I wasn't able to have a local variable in the function. You can, but you need all %20's instead of spaces.
May be getting multiple shape events when in drawPoint mode and attached via bind("geomapshape").
Not just shape, all events. If you recreate a map on the same div & rebind an event to a new function, it will trigger more than once.
While not in this release, I have a need to fix WKT parsing. Finished parse LineString & (single ring) Polygons.
Next on the list is pinch zoom. I can hook this into the scroll zoom mechanics based on pinch center & ratio of initial pinch bbox to current pinch bbox to scale the tiles.
Initially, I'm going to jump one scale level (or scale ratio) like wheel zoom. Later, when I update the whole interactive movement engine, I'm going to transition to the next scale level.
This will tap into the _wheelLevel variable, which I should possibly rename later.
Dropping out of multitouch (lifting one finger) will end interactive zoom & call setCenterAndZoom.
We pick the largest ratio between x & y changes.
Accidentally moved some code to where it didn't belong & broke interactive zoom. Fixed.
I would like to further have the service object's properties match html rather than css. I might rename this to just src.
===scroll & drag===
I need options to disable the default behavior of scrolling and dragging.
===html attr===
I think my options should reflect more like HTMl attributes than css properties. Including service object options. That might make me change visibility back to visible :( At least I'm not beta yet.
Scratch that, it's a presentation option and all presentation options should follow CSS. However, I may move it to a style property of the service object. Are there other style properties?
Only opacity.
I would like to support two-finger vertical slide as zoom on mobile devices but I'm not ready to write that up yet.
Hmm. Can I handle scroll without an option? I can detect page scrolling and set a timeout. If the user has been scrolling the page, we don't want to scroll the map. But, what if the user's cursor just happens to be on the map when they want to scroll the page. I'm keeping scroll, the developer should have control to turn it off all together.
I'm still thinking about service-level methods. I'm not going to add the *All methods right now and I'm not going to have the single methods dive into the services (other than find, which even in jQuery digs into sub-elements not in your collection). The table I wrote below won't go into the docs.
Almost done with the docs for this. I wonder if I can have the jQuery UI widget method find merge results when more than one element are used in the selector. Unlikely but it would be cool. I'm going to have to assume not for now but keep that in mind.
I am going to document that all service divs have the geo-service class. So, the default service will be both .osm and .geo-service.
It's quite clear to me that I should be able to call find on services. That will return shapes in that service. What does calling find on the map do? Should I have it search map and all services as planned or limit it to just map shapes? I have no idea what this would do in jQuery UI widget factory:
var shapes = $( "#map,#map .osm" ).geomap( "find", { type: "Point", coordinates: [ -71, 42 ] }, 4 );
What will be called, what's the return...just the first? Just the last?
For this version, I'm going to have find on the map only return shapes appended to the map. That will match how the other functions work and document that you cannot use the comma selector with the find method.
I need to get the final doc changes in for the $.geo.proj auto-handling. The definition of "map coordinates" is determined by the last use of center or bbox. The "map coordinates" are used as return values for the center, bbox, and the bbox property of the view object passed to getUrl. Now, how to write that...
Removing the rather extraneous label and style methods from my to do list and adding the much more useful replace method.
replace( existingShape, existingShape, style, label ) is the same as
append( existingShape, style, label ) but that's fine. If you want to remove existingShape and add a new one, you won't need two calls (remove & append).
I'm not going to add a shapes method either. I want that to be part of find. The next version of the find method should take various selector strings such as * and return an array of shapes. This also makes me want to revisit whether or not find can dig into services...I'll see what Peter thinks.
I feel like I want users to be able to write either:
$("#map .osm").geomap("find", "*") or
$("#map").geomap("find", ".osm *")
append, replace and empty are very one-item specific but find is a digging query operation. I think I just convinced myself that it should be different. It should dig into the services. That's what I think devs will expect. I already can't use find with more than one I'm already breaking the convention of the other three methods.
I'm not going to support the service selector in find's selector argument at this point. But I documented how it will work with a service element selector and that seems pretty cool.
Responded to an email asking about offline support. I wrote a few things in my reply that should give him some ideas. I'll copy them here:
I have thought of offline support. While something like that likely won't be directly part of jQuery Geo itself, there are different ways to approach it depending on needs. I have plans to put up some demos to give developers ideas but here's a short list:
1. Using the getUrl function to cache downloaded tiles in session storage on IndexDB. Since this function in the service object can do anything you want, it's perfectly fine to check some HTML5 storage options for tiles and returning, e.g., a data URI before attempting to access the Internet. Users will get roaming charges only when the images aren't in the cache. However, the amount of images you can store in the cache is limited by what the browser sets for the cache's upper limit. Some mobile browsers allow users to increase this limit, others don't. This is an option better suited for sites that want to show large areas with many zoom levels.
2. Pre-caching the whole tile set in HTML5's appcache. This is suited for a site that only serves a small area and not too many zoom levels. You would have to get a copy of all the tiles and list them in a cache manifest file. If the user zooms or pans outside the site's area, they can get some "no tile" image. The huge advantage is that users can first browse to the site on WiFi, the app will cache the entire map (which will take a while) but can then walk around and map tiles will instantly come from the local cache. The disadvantage is that HTML5 appcache is usually only 5MB which won't hold too many tiles.
I'm still trying to decide about whether or not remove should remove all references in all services or whether I need removeAll. There is precedent for xAll methods in jQuery. I will also need empty. This is too much for a4. Maybe beta or beyond.
method | map or service | function
append( shape ) | map | appends shapes
| | only to the map
append( shape ) | service | appends shapes
| | only to the specific service
find( Point, radius ) | map | finds shapes appended
| | only to the map
find( Point, radius ) | service | finds shapes appended
| | only to the specific service
findAll( Point, radius ) | map | finds shapes appended
| | to the map or any service,
| | will not return duplicates
remove( shape ) | map | removes shapes appended
| | only to the map
remove( shape ) | service | removes shapes appended
| | only to the specific service
removeAll( shape ) | map | removes shapes appended
| | to the map or any service,
| | will remove all duplicates
I'm going to implement buffer as an internal geo method for now & document it later. It's needed.
===two finger===
So, Google has settled on two finger single tap for zoom out. Fine.
Previous measure shows up if you destroy & create map after originally double clicking to end a measure.
In destroy, _drawCoords and _drawPixels are both empty. Where's the data come from?
When back into the new control, _drawPixels has values. There isn't a _drawCoords. Ah, widget factory was using old data, I have to make sure everything is cleared during create, including these two arrays.
Problem when you pan the first time while drawing in axisLayout image.
It's not just axisLayout image. It's also not measure, it's drawPolygon as well. Ok, this is new ;) I works fine in a3. Maybe something with the implementation of axisLayout.
Doh! Another "don't set arrays equal to each other" issue. Does this happen to other devs?
All that chatter about what version naming to use and then the jQuery blog points to this:
Also, here's the deal about the new plugins site:
===measure area===
I have to work on the measure area tool. Something's not quite right...oh yeah, I haven't implemented it yet.
measureDistance should be measureLength. The measureLabels object should have a length property.
I was going to bring our urlFormat property over from the old code but now I think I want it to be the same property on the service object. I think getUrl can be a function, but can *also* be a string for shorthand. This will obviously be a jsrender template string.
I'm going to keep the twitter-heat demo and also leave twheat as its own app.
Finally writing some service-level shape docs for 1.0a4.
I would like to add a wheel option. We have a wheelMode property on the internal control that can be a few different things. I would like this to be simpler. Maybe just "wheel" and have it be "on" or "off". Or a boolean? But a boolean would limit future additions.
I'm going to port measure over as pretty much how it's done in our original project, in that it will have its own dedicated label.
Trying to make the measure label look nicer than before. I'm adding a style to the document head just for the measure tool. I'm prepending it so designers can override any of the properties.
Pulling in jsrender for the measure label. I'm going to have to do it anyway for shapeLabel, may as well do it now. Works well for my needs, I'm going to document the measureLabels option.
===jQuery 1.7.1===
I'm still using 1.6.4 and will likely release that way. I'll have to test with 1.7. The notes say that .1 fixed a bug in mousewheel event. I didn't even know they had a mousewheel event. Maybe I can stop using the wheel plugin I've been using.
Judging from the layout below, I'm going to change textContainer to .geo-label-container and have it move around exactly like the shapesContainer. More like serviceContainer because it doesn't need to be the size of the frame.
#map .geo-map
===refresh polygon===
I'm still curious why I don't use toPixel on Polygon shapes as a whole? Why the loops? Right, I was thinking toGeodetic. geomap's toPixel function only takes up to two dimensional arrays. Updated both functions.
I need to pan both shapes and labels at the same time. I think I need a new container for these because drawing might be part of this as well.
===length & area===
Documenting and coding these because I'll need them for the measure tools.
===LineString middle===
There must be something in JTS that's similar to Esri's ILine.QueryPoint function but I can't find it. This is for getting the point along the line for the label. I want to add a generic function to $.geo. Ah, LineSegment.pointAlong.
Documenting pointAlong. Also implementing it! Works pretty well.
===line rotate===
I would like to rotate the line label based on the current segment but that will have to wait.
I'm going to merge labeling into geographics so that I can move the tech as a whole to indivdual services. That'll come later when I need to do service-level shapes.
I started porting measureDistance today but merged the branch in after being able to draw a line. The rest of it depends on being able to draw labels. Our internal library has _labelShape specifically for measuring but I'm going to merge that into the labeling engine for this release.
I need to update the append docs to include label before I do anything. Done. Since it's needed right away, I'm going to start porting labels over.
Can I re-use $shapesContainer for labels? I'd rather not keep track of a second div. However, I think $shapesContainer *is* a canvas element so that's not going to work. Yeah, it's a geographics widget, geographics appends the canvas. I can re-use that element...but semantically, it isn't correct.
That won't work anyway, I need these to exist at the service div level so they can be targeted by CSS.
However, labels not associated with a service would not be in a service div and would need their own div.
Currently, the layout is, e.g.:
#map .geo-map
I'm going to make this a real app with its own subdomain. I would like to use paging because the first page doesn't have enough results with a geo argument. What happens when there's no further pages. Is there a "next_page" property? Is is null?
The page will be more impressive if I try to geocode the location property to get more results.
Heh, this will blast a lot of queries at MapQuest. I'm going to have to store ids i've already processed.
That's soo much nicer!
Maybe I can get a couple old pages worth as well on the first search.
Twheat exists!
Time to start a4 docs. Hopefully this will be the last alpha.
I merged in the changes to support photos. It amounts to only a few hundred bytes minified and can be pretty useful. I couldn't find a good example service to use for the axisLayout demo.
Peter likes axisLayout as well...sold!
Trying this out for the first time. I can get image tiles from an image server but the zoom is all wrong and it's not centered. wheel zoom is also pretty wrong.
bbox min values are negative. I suppose that makes sense because it's trying to put the top-left corner of the image in the center of the window. It should be tring to put the center of the image in the center of the window.
MapBox uses an "official" tiling spec. In that spec the origin is in the bottom left. That doesn't mean the y-axis is flipped though but it does change how I calculate the tiling scheme. Maybe it does go up. That's awful, why would they do it different than web mercator?
Crisis averted, maybe? It looks like V2 of the MapBox API uses top-left origin and XYZ tiling:
Maybe not averted? Calvin is saying that TileStream itself (as in not hosted by MapBox) only has one API. That doesn't sound right.
This is wrong for image types the way we want to understand pixelSize with images. A low zoom means a low pixelSize which is opposite of maps. I seem to have fixed that. I'm getting closer.
Refresh is ignoring tiles on the bottom & right edge of the viewport.
The image still starts out in the middle of the page but you can move it around and zoom.
I forgot that while Peter's image server determines zoom levels backwards, I was going to handle that in the getUrl function of the service and have the pixelSizes of the tilingScheme be like normal. This works much better. Now I only have the top-left issue. That's not true, zooming bounces the new image to somewhere else, i.e., isn't smooth or correct.
So, I realized that at geomap zoom level 0, the image is way zoomed out and my center should be the center of the full image in pixels, so pixel width /2, etc. I changed that but my tiles are still misaligned.
Ha! I wasn't checking for undefined if you pass a zoom of 0. That means I wasn't setting the new center & pixelSize with updated values. All set. Now I'm only offset in the y location and I have a feeling that's because of the axisLayout.
Somehow, the osm class i getting on the serviceContainer element even though I'm completely redoing the services array at init.
I think for now I have to assume that at max zoom, the whole service fits in a tile and the center is in the center of the tile. I don't have a way yet to specify the center of a tiling scheme, only the top-left.
Pan is backwards as well when it creates the new bbox.
Fixed pan.
Looking good! interactiveScale is last. Then maybe I should support shingled. Wait, no, that was interactivePan, when pulling in new tiles.
Zooming twice is a bug but that's in core jQuery Geo, not this image addition.
Here's a link to a sample shingled image:
Actually, there are levels so that's a tiled image. Yeah, definitely tiled because the level argument doesn't allow fractional numbers.
===ie select===
I think I forgot a userselect somewhere because if there are no inputs on the page and you pan, IE highlights everything in blue. Every map tile.
Adding any input or link to the page fixes this. Also, adding this to inside the map div seems to fix it too:
<input type="hidden" autofocus />
That fixed nothing. The issue isn't with panning, it's with shift-zoom and happens no matter what's on the page with IE9.
===image coords===
I need a new property to determine the direction of the y-axis but I want it to be more generic. The difference is a different coordinate system, the side effect is the inverted ordinate axis.
Maybe just "coordinateSystem". I don't want to confuse users with the difference between coordinateSystem and tilingScheme though.
The full, proper term would be coordinateSystemAxisDirection or coordinateSystemAxisType. There seems to be a little precedence for CoordinateSystemAxis, found in GeoTools:
Nothing in JTS.
Hmm, axisLayout? Why not, it's short and specific. axisLayout = "map" | "image". Yes. I like it.
I added gzip to & all subdomains. jQuery Geo (minified & gzipped) is now 17k and falling!
I don't like that mouse move events seem laggy with this release. I need to find out what's different. I thought it was that I'm sending move events even while drawing that removing that hasn't helped.
Wow, geomap._refreshDrawing was terrible and geographics._drawLines needed a little tweaking.
===return false===
I didn't have any return falses at the end of my event handlers. I hope that plus the drawing fix makes panning better.
Oops, I went too crazy and added too many and wasn't letting the browser grab events it needed. Chrome's type=number input went crazy up or down if you didn't move the mouse away.
I've done what I can. The issue appears to be with Chrome or something I'm doing with Chrome. Drawing and panning speed is tremendous in IE9 and Firefox 7.
Wow, after any timeout, Firefox stops checking for watchPosition? Is that part of the spec? Nope, not part of the spec. Oh, it *is* part of the spec if it fails due to timeout. It does sound like it's not supposed to trigger until the position changes despite what you put in maximumAge.
Time to redo the shapeStyle example in a much more awesome way.
Did I miss something? jQuery UI widget factory isn't complaining that shapeStyle isn't an option on the widget even though I haven't added it yet.
New demo is super-cool!
I almost had this function clear the shapes geographics until I realized that it's recursive if there's a GeometryCollection. Can't do that.
Cleaned up the wording for append, remove & empty. Also, going to have append allow style only, refresh only, or both.
Due to performance, I'm going to disable the auto refresh after interactiveScale of shapes if the number of shapes is over a certain limit, say, 255.
===tile paint===
Another app I want will be It won't actually use jQuery Geo but will repaint tiles on the fly for you based in an input URL and color changes.
There's a bug trying to convert some positions of a town near Concord in the voting demo. I wonder what's different about that geometry.
The shape is a multipolygon which I am not handling properly. It can be a quadArray. I also removed all the $.each calls which should speed things up a bit.
All set now.
===ArcGIS Wrapper=== will take an ArcGIS Server endpoint and spit out the jQueryGeo you need to initialize a map to that service. It should handle both cached and dynamic services.
I'm working with Calvin Metcalf at MassDOT attempting to push all the data into jQuery Geo. I might want an option to turn off scaling vector data because it's rather slow. Maybe only do it if they have WebGL.
Disabled it for now.
The refersh property must be made public, pushing large number of features isn't useful without out.
I'm at WhereCamp Boston 2011 and going to try to finish Alpha 3 while I'm here starting with making id optional.
Was getting undefined when a user passed nothing as in the simplest test.
So, I forgot that class is a reserved word. I'm not sure what to do about that. I can make id optional for now but I'll have to decide about class as a property name. I know as an object literal, I'm supposed to enclose the word in quotes but that's not going to look right for the user who wants to use this. I might have to call it cssClass or something. I'll find out what jQuery uses.
Google Closure won't even minify the build with the word class used as I'm using it. When I'm creating an element using jQuery's argument that takes an object for attributes, what do they use? They require quotes.
I'm still storing the service state by id. Since both id and class are optional, I think I need to store it as an array. That's not true, I can store an id on the service object via $.data. The id can be $.now. I wonder if $.now actually has different values if I'm creating more than on service at the same time? I will need to test and potentially use a different means to create the id.
===service create===
I'm going to assume that the service doesn't already exist during create. Not sure if that's a good idea though. Maybe for now, I won't and I can make the create code smaller later after I have time to test.
I completely forgot that I'm going to store the entire service state via $.data. That will make things a lot easier.
Seems to work ok.
===double click on unloaded===
When a singled image hasn't loaded after pan and you double click on empty space, the zoomed area seems wrong.
Andres from Google is showing radius query using fusion tables. Seems like something I can do with jQuery Geo.
I might have to support kml.
I should support typing a url to a geojson file to append all of the json.
Both shapeStyle and drawStyle get and set a plain JavaScript object and should be widget "option"s. While changing them does have side effects, they perform no action themsevles.
I'm leaving centroid in a3 but removing support for GeometryCollection for now (in the docs & code). That can come later.
No sense having the two lines that support arrays, they'll never hit a valid switch case and it's not in the docs.
===service state===
I finally moved it to a $.data store on the services container. It was getting messed up moving between pages in jQuery Mobile when one of the pages had a map.
Shingled maps don't resize properly. I think I have to have a resize method in there & call it from geomap. All set, I had to mark the current scaleContainer as not being for the given scale any longer and re-center it.
I can't decide about this property of the service object. I need an API audit from Bocoup :(
Since I have opacity and visibility in shapeStyle, and I know I'm not going to change them, I think I do want to have the naming synergy because I do have opacity in service properties that I'm not going to change. Ugh, but the toggle method takes a true or false value. But so does jQuery's and that changes a CSS property from one text string to another.
===change service object===
Unlike the shape objects, I think it's fine if I change the service object's visibility property. It's sort of awful to see the check for undefined & I change it anyway when they use the toggle method. Why not just set it to "visible" when I create the service?
===draw pan===
The current version didn't get the code ported over that disables inertia while drawing. I think I need to put that in because without it, the drawing does feel too fidgety.
I was calling _panEnd instead of _panFinalize for the draw modes.
===draw polygon===
Finally ported this code over. Seems ok.
I would like to make an app that lives at and has some useful functionality similar to Google maps but uses all open data.
===push it===
jQuery Geo is still functional in Chrome drawing all of the census tracts of MA. That's over 55,000 points and 3,000 features. Not too bad.
I've ported some initial line code and actually made it much more elegant than our internal one.
The shingled demo needs some work.
I pushed out a great new bbox example page. It links to a live jsFiddle even so people can play with the code.
===jQM buttons===
I did have to make the full screen map an external page. It worked ok after that and the back button still works.
jQM has virtual buttons to handle either touch or mouse input (some devices have both at the same time): vclick, vdown, vmove & vup. However, they don't handle multi-touch so I think I'm going to have to stick with what I have at the moment. I can't require jQM just to have jQG work on mobile.
Porting our shape drawing code over finally. We're getting a new geographics widget to differentiate drawing from appended shapes.
I forgot to write about the drawStyle method. This one might actually be a true option as it will never be service-specific. It can only apply to the map widget.
===draw functions===
I need to rename some things. I've been using a few old names from our internal code but they don't quite make sense with some of the newer names of public properties. Mostly, shape should mean anything added via append and draw is the actual in-process drawing.
Two internal method names should be: _refreshShapes (instead of _drawGraphics) & _refreshDrawing (instead of _redrawShape)
===drawPoint dblclick===
As the docs say, a double tap will zoom in just like in pan mode and not trigger the shape event.
Oops, my underlying geographics widget is sharing the same canvas context. Flicker city! Ah, much better.
Because I'm delaying before I trigger the shape event, it feels slugish. Maybe I can drop the delay down to 100ms. Too fast, I'm getting the shape event.
I gave a presentation to jQuery Conference Boston 2011. I didn't have much time because I was sharing a block with another speaker. So, my presentation was rushed but I still think a few people interested. I will have to get better at conveying that this is not a wrapper for Google Maps or OpenLayers. We do not host any 3rd party controls.
===jQM buttons===
With a jQuery Mobile controlgroup or navbar on the same page as a full screen map, I get huge performance issues on Android. iOS seems ok with it. Desktop browsers are fine. The map doesn't pan while sliding your finger but it does show up in the new location when you let go.
Removing the navbar completely didn't help. I think that unless it's a small in-page map, I'm going to have to make the page external.
To test these new bbox functions, I'm going to redo the bbox example page.
I can store a tiling scheme in JSON but just realized that I can't store a service definition in JSON because of the getUrl function property.
Documenting and adding the zoom method.
Made bbox public. It's also now storing projected coordinates. $.geo.proj can also accept bbox arguments now.
===disable auto-proj===
Peter suggested (for actual GIS users) a way to disable $.geo.proj but keep the object where it is. The situation is: "I know I'm working in a projection, and I want $.geo.proj to match that projection, but I don't want it to attempt to auto-project coordinates I pass to $.geo functions or geomap because I'm going to send it projected coordinates, but I do want the object around for when I might want to un-project some coordinates to geodetic."
That's wordy but it does make sense.
However, instead of adding a boolean on $.geo called autoproject and telling people that they can shut it off, I'm going to test diving into arguments to determine if they are geodetic and auto-projecting myself. There will be a performance hit but I need to test if it's too much or worth the simplicity. I think I'm going to find that it's worth the simplicity. I can then remove A LOT of words from the docs about if $.geo.proj is null, blah, blah.
That's fine for input values, but what about auto-unprojecting output values? Maybe I do need that boolean property on $.geo? Or I can store the last way center, bbox, or bboxMax were set and return values in the same format. I would rather it not be that tricky though. If I do add a property, it would only need to be for geomap. The $.geo functions are stateless.
Working on WKT.stringify/parse. There will be a $.geo.WKT object.
Moving along, made the frame of a nice test page too.
===destroy memory===
A destroyed geomap remembers what was in _graphicShapes. This means that any other private property initialized with _prop: default, is remembered. There could be other issues...until I replace all indivdual properties with a single state objects. For now, I'm going to reset _graphicShapes to [] in createWidget.
Somethings wrong with destroy, can't create after. One thing missing is that resize is called (by jQuery Mobile?) after the call to destroy which causes a script error. I have to make sure I unbind resize. Huh, I've never had to unbind a handler before. Heh, destroy erases any content you had inside the widget before you created a geomap.
Found bugs in serviceType.destroy and graphics due to code refactor. The CDN, while wonderful, takes too long to update. I suppose it's not the best idea to put the test branch on the CDN. Done. I'll still occasionally copy test to the CDN but mostly I'm going to update the non-CDN'd version until I know things are ok.
Alpha 3 docs online & tweeted about!
My code refactoring broke auto-resize. I wonder what else I broke :)
I renamed the compiled JS files to match what has for jQuery itself and jQM. jQUI isn't on there, which is odd.
===widget factory syntax hack===
Testing if the syntax I want is possible with the jQuery UI widget factory pattern. I only want the one widget, but I want to be able to call some functions on other child elements. I already hit a snag. Calling .geomap("toggle") on an element that has not been initialized as a geomap widget doesn't trigger _createWidget, _create or toggle.
===serviceTyep files===
I'm going to split out the service type objects into their own files. That'll help me make sense of the geomap.js file.
To do that, I had to move _serviceTypes from being an option of geomap to a propery on $.geo itself. This will help third-party service type plugins down the road.
===widget vars===
I think I have to move all the widget vars back into the object passed to $.widget so that they don't conflict with each other, e.g., multiple geomap widgets. As they are now, I think they're all plugin-level widgets.
This is awesome. It looks like I can get the syntax I want. Now to figure out the best way to call the method in the parent geomap widget from a service widget.
It seems like the vars created in the closure supplied to $.widget are still used by all widgets on the page. Do I really have to store state in a data object on the element?
Yes, they are shared. Yes, I will have to figure something out.
I just had to plaster my code with this's. I don't like it but it now supports the toggle/opacity syntax I want and *I think* also supports multiple maps on the same page (I think). That's going to increase my minified size quite a bit. I'm going to have to go back and see what I can do to clean it up but I'm choosing proper functionality over code size for the moment.
I'm trying to clean up the docs and change notational $.geo to jQuery Geo, but not mess up anywhere I mean to reference $.geo the namespace.
I have a better plan for service id. I'm going to keep my plan for having the presense of a name property create a hidden input but I'm going to allow the service object to have a class. The class will be applied directly to the built-in service divs. I will still apply data-service-type="tiled" or data-service-type="shingled" to the divs. To apply certain methods to specific services, you will now target the service class under the map element:
$("#map .osm").geomap("toggle", false); // this will hide OSM.
===service create===
I'm going to require that the service type's create function return a jQuery collection of one item that is addressable for that service. It doesn't really HAVE to have anything in it but I'm going to store service state on it using $.data($el, "geoServiceState", {}) or something.
Upgraded to jQuery Mobile b3 & added some color to the headers of various doc pages.
===service id===
After talking to Peter, I'm going to allow class and id with a note that if you use id, you'll have to be careful of adding more than one map on the page. I like this plan. Also, if you do it by id, you can target it directly:
===widget tricks===
I'm not sure I can do the selector tricks I want with the widget factory. I may have to change my docs & design if I can't do it elegantly :(
I may be caching too aggressively. I think I should remove caching from $.geo.bbox and instead cache inside of append and clear the bbox cache in remove. I really only need it in the find method.
It's time this project got its own nice site. Also, (mt) is faster than my previous host from places farther away than MA.
Working on the event docs.
I was originally going to rename id in the service objects to name so I could use it as an input name on a hidden input. However, I'm now going to require id but allow name as an optional property. If present, it will create the hidden input. This is now a future task and will not be in alpha.
While adding the refresh argument to append, I started thinking again how I want to implement service-level graphics. It would be very nice if I could have the map>service syntax to jQuery and call append, remove and empty on that. I think I defined the syntax a while ago...yeah, see "On shape functions" from 2011-06-02.
The issue I have is that a page can have two maps. The default service has id=OSM. So, if I allowed $("#map #OSM") syntax, it would cause the page to have two elements with the same id, #OSM. However, $("#map [data-geo-service='OSM']") is way to wordy. I'll have to discuss this with others later as this is not an alpha feature either.
FOSS4G is an inspiring conference. I gave my talk and people seemed interested. There was a question about Google. I answered that it's illegal to use them and Chris Schmidt mentioned on Twitter that it's not illegal, it's just hard. We're talking different things. jQuery Geo would use Google tiles directly, which is against license. We will never host a third party widget inside the jQuery Geo div as part of the core functionality. OpenLayers wraps the official Google widget to get around the license restriction (since it's the official Google widget, there's nothing wrong with it) & keeps it up to date (or slides it around) when the user interacts with the OL map. I might do something similar as a blog post when I open up the service types plugin system but until then, but it won't be part of jQuery Geo..."here's how to do it if you want", type of thing. The developer would have to pull in the Google maps API themselves.
I'll have to see if JTS uses Point or Coordinate as a return value & match it.
Centroid needs to use $.geo.proj for accuracy. The centroid should be calculated in web mercator & projected back to geodetic.
The way we do projection is different than how GIS does it. Usually, when you define a projection, you work in non-geodetic coordinates because the coords have been projected to a flat plane. With jQuery Geo, you work in projected coordinates (I call them non-geodetic) when you set $.geo.proj to null. This can be a little confusing but I think it works.
The first thing we would have to do internally is set $.geo.proj to null because we use pro
===bbox proj===
bbox might be an issue. a bbox in geodetic coordinates (lon/lat) that is a rectangle, will not be a rectangle in web mercator. That's not a problem with setting the bbox property on geomap but could prove interesting for the bbox of geometry objects. For example, the bbox of a square polygon will not be a parallelagram in geodetic coordinates.
SUGGESTION: Calculate & cache bbox in projected coordinates
SUGGESTION: Document that lon/lat bboxes will not appear to be correct?
===bbox cache===
Peter and I got into a talk about caching bboxes. He's worried that we will have too many floating references to objects that cannot be collected. That is a valid point. For example: a user creates a polygon as an object literal, they then call $.geo.bbox on it, then the function ends. We will have a cache of the bbox, but most importantly the cache will reference the original polygon so the browser cannot remove it from memory. I agree that this isn't a great situation. However, the performance benefit gained by the find method is hard to ignore. Also, this only becomes a problem when the developer calls bbox directly. Even though we call it during the find method (building up cache), they are all removed when the dev removes shapes from the map with the remove method. I also know I need to research more about how $.data works with objects. I may be wrong about the reference/memory leaks.
===point bbox cache===
Now that I know I should cache bbox as non-geodetic, I think I should revisit my jsperf regarding caching a point. Since there's going to be much more calculation involved in $.geo.bbox, I might want to cache points. However, I think I should only cache them if $.geo.proj is not null. When it's null, non-cached points will still be faster as per my original jsperf test.
The new shape event will need a new event type. Position event won't cover it but it's similar. I'm not 100% sure if I should merge them. The new event type will be a shape event.
While zooming in, Chrome skips zoom level 12. I wonder if that's a bug in the control. It is. It's a rounding error in _getTiledZoom. Using floor and * instead...fixed.
Contains is spatial ref agnostic and is called by distance.
== 2011-08-07 ==
=== bbox ===
I think I'm missing something from my bbox description.
=== append ===
I would like to say that devs can call append again on a shape and it will replace the existing one and clear the bbox cache. That might be a good compromise for bbox cache clearing because I don't want a method specifically for that. Maybe, I'm not sold on the word append replacing something that's already there. Does jQuery have a replace function?
SUGGESTION: geomap - append should allow re-append of existing shapes, replacing the old one and clearing the bbox cache
=== bbox ex ===
I'm writing an odd example and I already forget if fromGeodetic can take a single position. It can, according to my docs :)
=== from/to pos ===
I keep going back and forth about coordinate vs. position in terms of words. I almost thought of changing fromGeodeticPos to fromGeodeticCoord but they /are/ called positions in the spec so I'm going to leave it. Again, it's spoken words (of which I suppose I am now including API function names) and code, which is GeoJSON object properties and arguments. Still confusing, this will never be settled so I'm dropping it.
=== bbox cache ===
Oops, I wasn't namespacing my data. I thing it has to be geoBbox because the namespaced data attribute would be data-geo-bbox.
== 2011-08-06 ==
=== alpha 2.5 ===
I released a new version last week and it seems to work well. I'm happy with it. On to documenting the features of alpha3!
=== label ===
I'm going to add labels and I think I want a label argument to append, however I want both style and label to be optional. In other words, you can pass a shape and a label. The label argument will be a string of html or a jQuery collection of elements to append to a label div. The outer label div is controlled by geomap. It will have a class on it, geo-label, if devs find they need or want to control it that way, i.e., add plain text and control the label style using the class.
=== jQuery a plain ===
Is a jQuery collection a plain object? Not according to this fiddle:
So, I will have two optional args: style and label. Style has to be a plain object. Label can be a string or jQuery object. I'll say style comes first but they can be in any order.
=== shape props ===
Even though I have args on append, I will eventually allow both style and label properties on the GeoJSON object. They're not standard but not illegal according to the spec.
=== stored label ===
For speed, I will have to build the label HTML during the call to append, whether or not I use the shapeLabel property on the map or the label supplied during append.
=== override ===
The label supplied to append will completely override the map's shapeLabel property.
=== centroid ===
While I would like a LineString's centroid to be a point along the line so I can using it for labeling, that's not the accepted definition of a centroid of a line. According to JTS, it's calculated like a polygon, except when there is a polygon as part of a GeometryCollection. In which case lines and points are ignored when calculating centroid.
=== line label ===
Checking to see if JTS has an official point-along-line function that I can add w/o creating my own name. It doesn't seem to. I just decided to not label on the centroid for lines but on the "center point" of the line. As you add more points, the label will move further along the line.
=== envelope & bbox ===
So, OGC simple features doesn't seem to define an Envelope class. The Envelope function is defined to return a Polygon, eww!
=== ogc text align ===
They do define text alignment options called HorizontalAlignment: start, center and end. Might be useful later for text label options.
=== $.geo & proj ===
Internally, I need to call the geometry ops in $.geo and I will already have a projected bbox or geometry object. I need a way to tell methods such as $.geo.expandBy to not call $.geo.proj.fromGeodetic even if $.geo.proj is not null. I think for now I will have an internal (and undocumented save for here) argument at the end called ignoreProj. If truthy, it will not call fromGeodetic. A false value or undefined will call fromGeodetic if $.geo.proj is not null.
The documentation will always say fromGeodetic is called if $.geo.proj is not null.
SUGGESTION: Add an internal ignoreProj argument to $.geo geometry functions.
=== scaleBy ===
I haven't used it yet buy my original port of the scaleBy function was wrong. I was calling expandBy which would make scaleBy(bbox, 1) actually increase the size of the bbox, however, scaleBy(bbox, 1) shouldn't change the size at all. Also, expandBy was wrong basing itself on center instead of just modifying the min/max values directly.
=== geodetic bbox ===
I forgot that from/toGeodetic don't currently support bboxes. What am I doing already in geomap? Ah, right. I only needed it once (the bbox property) so I'm converting to two positions by hand. I think I should make a conveniance method in $.geo.proj. fromGeodeticBbox or something. I'm not going to make it public. Devs shouldn't have to call it, they can work in whichever projection/non-projected state they set $.geo up as and the public functions can handle it.
SUGGESTION: add private _from/_toGeodeticBbox methods
I did remove the, "if $.geo.proj is not null X first calls fromGeodetic..." shpeal that I had in all the bbox methods because it's not accurate. I won't call from/toGeodetic, I'll call a private method.
Actually, I should be able to detect a bbox vs any other geometry in the *Geodetic methods. It will be an array of 4 numbers, so .length == 4 and $.isArray(value[0]) == false. Maybe I'll put bbox conversion into them after all.
== 2011-07-30 ==
=== alpha 2.5 ===
It's been too long since I had a chance to work on this and I want to get an alpha 2.5 release out.
I need to push this back in an change my current branch name. I think it's alpha3 at the moment.
=== jsperf ===
I wrote a perf for point & linestring bbox cache testing. The test makes me think doesn't do what I think it's doing. When I cache the bbox in a local var, it's very fast but when I cache with data, it's not.
* Here's the point test:
* Here's the line test:
It's always faster to test points by themselves, i.e., don't worry about checking for a cached the bbox.
=== branch ===
I was on master, so I pushed, then created & switched to alpha2-5.
=== opacity ===
When developing the heat map example, I remember running into an issue where I couldn't get the opaicty to look right between the border and center. Maybe I fixed it somewhere else because I can't seem to reproduce that.
I can still get it on the latest fiddle of the heat map. It's when the opacity is 1 and the strokeOpacity is 0, the stroke still shows up but it should be hidden.
I still can't recreate this on the shapeStyle test page :( Ah, but the twitter heat example has the issue.
Turns out I was or'ing the stroke/fillOpacity with regular opacity in _getGraphicStyle. That's not the right place to do anything with them, and never or.
=== service opacity ===
I'm going to pull in the service opacity method from AppGeo.Web as "opacity" on each service object, like refresh.
That's done. I haven't documented/implemented what happens if you don't pass a service id. It's required. I'm not sure what I want that to do yet.
=== visible ===
When starting to think about geomap.toggle, I realize I have a naming conflict so to speak. The service object has a boolean visible property while the shape style has a string visibility property. I think I want to change the service to match the shape style. I don't think there are any attributes in HTML that pertains to visibility so I'm going to match CSS even in the service object which is more internal and less graphical. That said, I don't want to start renaming things in alpha 2.5 so that'll wait until 3.
SUGGESTION: Rename service.visible to visibility having either "visible" or "hidden" values
=== service props ===
So, I noticed that when a service is created, I don't modify the service objects to fill all the supported properties. So, when toggle is called, there's potentially not an initial visible property set.
I think for now, alpha 2.5, I will have the toggle function assume that there could be an undefined service.visible. The refresh method does the same. Later, though I think I might want to set defaults during _createServices.
=== proj ===
New projection code seems to work and is awesomely 150 lines shorter!
=== resize ===
I'm going to hook into the window resize event automatically but I will still need a resize method later in case the dev changes the div size/css.
SUGGESTION: Add a resize method to let geomap know the div has changed size programatically
I'm not sure of the correct way to kill & remake graphics now that it's a jQuery UI widget. It appears that I can call distroy & re-create it.
Resize, is working though when getting smaller, there is a space for the scroll bars. I don't remember having that issue with the internal AppGeo.Web control. That is an issue to tackle after alpha 2.5.
=== dbl tap ===
What is a thumb? On touch devices, and other soft-dblclick devices I don't take into account that the second click/tap might be too far from the first to count as a tap. There is no move event to cancel. I'm now calculating distance between the two based on _anchor (previous) and _current ( current :). This will need testing. I'm setting it at 10px for now, line 1480 of geomap.js as of this writing.
== 2011-07-19 ==
=== wkt ===
Wrote up some to-WKT code for our internal control today. WKT will also be supported by parseWKT and textify methods in $.geo.
SUGGESTION: Support WKT with $.geo.parseWKT (like JSON.parse or $.parseJSON) and $.geo.textify (like JSON.stringify).
=== centroid ===
Wrote up some centroid code for all but GeometryCollection as well for our internal control. Code similar to this will end up in $.geo.centroid.
== 2011-07-15 ==
=== presentation ===
My first real talk about $.geo went well, I think. Next up is FOSS4G in September and, possibly, jQuery Conference Boston in October & Harvard WWW in December.
=== alpha 2.5 ===
I think I want to push out a bug-fix release of the alpha 2 tech. I'll tag it as alpha 2.5 in github but overwrite the alpha2 js file on host. Well, rename the old one as alpha2.0 in case people find a bug in the new one.
I need to write down exactly what to do for alpha 2.5.
=== shape images ===
People really want images on shapes, particularly points. I'm removing this feature from my TO DO list:
* geomap - Document and implement passing a function to shapeStyle and append that returns a geomap style object based on feature or geometry properties
because I have a much better plan that involves the label div. It will be a normal div and have a class. Each will have relative position and designers can manipulate it however they want.
== 2011-07-12 ==
=== fiddles ===
Some fiddles for my demo on Wednesday:
# show a map:
# show a map & zoom to boston
# show a map & zoom to geolocation
# add a location search
# add a twitter search: rpp=100
# use map center as geocode, radius=(pixelSize * width/2 ) / 1000
# change style to heat map (16x16 size 8 border-radius)
# update on bboxchange
# show tweets in popup
== 2011-07-07 ==
=== bbox ===
I added bbox caching! I even check to see if the GeoJSON object has a bbox property, which is legal. There's no way to update the bbox but that'll come later.
=== distance ===
I almost tried to have distance support taking in a Feature but that opens a whole can of worms. I'm going to fix find to only send base geometry types to distance.
DOCUMENT: geometry methods will only take base geometry types (Point, LineString, Polygon & Multi*) or coordinate arrays
I had some weird comment on this method, it should be documented to only take base types, as I just said.
=== form input ===
I was talking to Chris last night about what geomap does that others don't and he reminded my about the idea I had of keeping a hidden input of the shapes as WKT. This would mean that I had to have a property on geomap for the map's name and also definitely change the service object to use name instead of id for when I add service-level shapes. WKT becomes a problem though when they've added features. I suppose I would dig into the features and only pull the geometry.
=== json ===
It's been a while since alpha 2. I'm working on a demo that draws the US state boundaries as graphics.
== 2011-06-30 ==
=== min ===
Srsly? I wasn't using minified jQuery in my examples? Wow.
== 2011-06-29 ==
=== alpha2 ===
Released alpha 2. I don't think anyone's really using it yet though.
== 2011-06-28 ==
=== on services ===
I think it would be nice to deep extend service objects that come in via the services property if a service with the given id already exists in _currentServices. This way, you could set the initial opacity of OSM by simply sending {services: [{id: "OSM", opacity: .8}]} during init.
SUGGESTION: deep extend existing service objects when services property is set
=== on opacity ===
I was beginning to try to throw the opacity & toggle methods into alpha2 but setting the services property is too flickery. I want to do it more like the old widget but that will require adding opacity and toggle methods into the services types. That will have to wait. It will be much faster to call the opacity/toggle methods on geomap than to set the services property each time. I will have to document that.
SUGGESTION: require opacity and toggle functions in the service type objects
== 2011-06-27 ==
=== on events ===
I almost forgot that I don't want bboxchange to fire when the developer changes a property in code. Unlike jQuery UI, my events trigger only when the user does something.
=== on alpha 2 ===
I'm trying to put this together.
== 2011-06-24 ==
=== on shape methods ===
I'm almost done. I need to finish empty and then I have what I wanted for an alpha 2 release!
=== on Point vs. coordinate ===
I think I'm going to settle on using Point objects everywhere except the projection functions. Which means I need to change find to accept a Point instead of an array. This should work out because the position events already send GeoJSON objects instead of position arrays.
=== on geometry ===
contains doesn't care about projections. Lon/lat values do not need to be projected.
I got done some of the geometry functions in $.geo but I'm leaving them private for now until I have a chance to document them and fully implement them.
=== on proj ===
Finished changing the $.geo.proj docs to explain that it will convert any GeoJSON coordinates array. I think I will also change the requirements to implement other projections by having the developer only have to override single position conversion functions (instead of worrying about the dimentionality of the passed array). Done.
=== on find ===
Now that proj is more powerful, I think I can handle find.
== 2011-06-18 ==
Accidentally coded append differently than how I documented. Will fix the code. Documentation FTW!
I can't decide if the geometry functions in $.geo should only accept the base geometry types or not. Initially they will not. I don't want to even think about getting into $.geo.distance(multiPoint, geometryCollection).
$.proj should go up to a three dimensional array to handle the coordinates in a Polygon. Go big or go home, I'm going to support four dimensional arrays so that I can get MultiPolygons as well. That will handle all of the GeoJSON types that have the coordinates property. If you have a GeometryCollection (geometries property), a Feature (geometry property) or a FeatureCollection (features property), then you're on your own.
I may change every mention of "web mercator" to "spherical mercator" to be more specific.
== 2011-06-17 ==
Attempting to change drawPoint from ovals to rounded rectangles. Shortcutting to drawArc if the width/height/borderRadius are the same.
Since I plan to make geographics public at some point, I thought I might make the drawPoint/Line/Polygon functions take actual GeoJSON shapes but I think that might conflict with some functionality internal to the geomap during digitization...I'll have to revisit this.
I seriously need to settle on the word "position" in my code when referring to an array containing an x/y. I use coordinate a bunch because that's what I used in the old project. Oh, but the property name of the GeoJSON object is coordinates. Heh, this is so confusing :) Ok, as I have been doing: coordinates in code, position in documentation.
I'm using cowboy's safeParse but can't tell what it's guarding against. I thought it would always give me a number but that's not the case. Guard against NaN or undefined?
Should drawing a bbox ignore borderRadius? I haven't decided.
You can fill and then stroke the same path, just sayin'.
Point graphics now draw as rounded rectangles. There's weirdness if your sizes are a little off though. I should probably start clamping values to each other like width & height to borderRadius. Yeah, if either is smaller than borderRadius the drawing gets weird. Maybe I should clamp borderRadius instead. Probably. Yeah, have to clamp borderRadius to min(width, height)/2.
I don't think you can disable fill by setting style.fill to "", but you should be allowed. It shouldn't be required to set fillOpacity to 0.
I just dropped a couple loops out of my graphic drawing in geographics. Should help a bit :)
== 2011-06-12 ==
I'm finally pushing the renaming changes to the main project.
=== On examples ===
I talked to Boaz at Bocoup the other day. He suggested cleaning up the examples. I already had this in mind but I should probably do it sooner rather than later. Especially the simplest example. It will look nicer if I cut the div down to 256x256 to match the initial tile I think (done, it already feels better). I do need to keep the examples specific and don't want to add any HTML or JavaScript to them that does not directly relate to the feature I'm testing in the example.
He also suggested unit tests and an API audit, both of which are great ideas and much needed by $.geo.
=== On ovals ===
Peter and I discussed how points are drawn and what width and height mean in geomap styles. We both agree that ovals are not very useful or used constructs in GIS and it would be better to have rounded rectangles. Therefore, I am dropping ovals and intead supporting a borderRadius property. Circles are still possible as long as your width, height and border radius are all the same, you will have a circle. This will be the default.
=== On double-click zoom ===
Peter and I both agree that double-click zoom should operate similar to mouse-wheel zoom in that the bbox should scale according to the placement of the mouse cursor during double-click instead of completely re-centering. You will notice that mouse-wheel feels right and double-click can be confusing.
SUGGESTION: Double-click zoom should scale according to cursor location instead of re-centering
=== On position events ===
I cannot decide if I should officially make the geo argument passed to the position events (move, click, dblclick) a true GeoJSON Point object. The only difference would be the presense of a type property set to "Point". However, the extra pixels property that I have on the geo argument is not part of GeoJSON and will remain in memory. Also, if a developer pushes the new object to a database they are storing extra information that they don't need and will be useless later.
Is the pixels property even that useful? The dev can call geomap.toPixels if they need it. I added the pixels property just because I had the pixels lying around in the internal handling of the event. I think I might just not pass them. It would be more useful to a developer I think to have a true GeoJSON Point object that they can send to geomap.append or a database without worrying about having extra useless data stored with it.
SUGGESTION: Remove the pixels property from position events and add the type property to make the event argument a true GeoJSON Point
I just updated the docs and changed the implementation. I already like this a lot better and am now thinking that the bbox event type could actually send a true GeoJSON Polygon with the bbox property set. That would be totally within the GeoJSON spec and might be useful. That's a bit of extra code on the widget's side though so for now I'm going to leave it as is. I can add that feature later since the current implementation (an object with just a bbox property) is already partially in a true Polygon's spec.
FUTURE SUGGESTION: Send a true GeoJSON Polygon object as the geo argument of bbox events
=== On returning jQuery collections ===
I need to better design the return values of the shape methods other than find & shapeStyle. Should append, remove and emtpy return the jQuery object of the map elements that the call originated from? Probably.
I just tested and yes, as long as you don't issue a return statement inside a jQuery UI widget method, jQuery UI will return the original jQuery collection for you.
== 2011-06-10 ==
=== On geographics ===
I am going to leave drawArc in the graphics widget. The drawPoint method will draw our default point shape (rounded rectangle) but, in the future, when custom drawing is in, a developer can use the drawArc if they want.
=== On proj ===
Peter has updated web mercator <=> geodetic code for me to drop into $.geo.proj.
== 2011-06-06 ==
=== On renaming shape functions ===
Renamed the shape functions. That was annoying but I'm glad I only had addShape implemented.
=== On jQuery UI widgets ===
The widget factory does hide methods that start _ from being called. So much for renaming drawArc to _drawArc and still calling it from geomap.
DEPRECATED SUGGESTION: Turn geographics into a NON-jQuery UI plugin
Did I totally get the scoping wrong for the jQuery UI widget? I have local vars in my initial plugin closure. Will they conflict if there are more than one map?
SUGGESTION: Verify that vars local to initial closure do not conflict when multiple maps are placed
== 2011-06-04 ==
=== drawArc ===
I just realized that by dropping geographics.drawArc in favor of drawPoint I am losing the ability to draw the circles I need for digitization modes. I wonder if, before I turn DrawPoint into a box-like function, that I should copy it to _drawArc. Will jQueryUI.widget let me call it from geomap?
=== shapes ===
Chris and I were talking about merging append (previously addshape) and find into one call: shapes. If you pass a GeoJSON object or array of, it will add them. Otherwise, it will find them. Thinking about this today, I don't quite think that's the way to go. I mostly feel that calling geomap functions to manipulate shapes is closer to adding elements to a jQuery collection. In other words, to call the geomap functions you must have already wrapped an element with jQuery, $("#map").geomap("funcName"). When you wrap elements with jQuery normally, you have to call append, find, etc. Geomap will work the same with. Of course, I do still want the syntactic sugar later: $("#map").append(geoJsonObj);
== 2011-06-02 ==
Who needs a blog. I feel like the best place to keep a developer journal is in the project itself so here we go.
=== On addShape's style argument ===
I showed Peter the shapeStyle demo. He expected that the shape-specific style applied via addShape would only override properties set during addShape. Further manipulation of the base shapeStyle would cascade to the shapes for any properties not explictily set. You know, like CSS. This is obviously the correct way to go and I already forget what made me code it the other way last night. Likely that I was coding at 2am and thought that if a user was passing a style to addShape they would want ALL style properties set in stone for that shape. That is not the right idea. If they want all properties set in stone, they can override all properties in the style object sent to addShape.
I changed the implementation before leaving work.
=== On storing & modifying style ===
My initial implementation drawing shapes in $.geo is very similar to how I did it with our internal control. I also showed Chris the shapeStyle demo and explained how you can add a style that's different from the base style on the map. He suggested that there be a way to change the style of an already added shape. I figured that I could make addShape update existing geometries instead of adding a new one but the syntax felt wrong. An updateShape method would work and could pass right through to addShape internally.
He also suggested allowing access to the internal GeoJSON->style map (as a return value for addShape) so they can maybe change the existing styles that way. However, something doesn't feel correctly designed about that.
We discussed attaching the style to the GeoJSON object. I already had supporting that in mind. If the user happens to have put a style property on the GeoJSON object before passing it to addShape, I would use that when drawing. A style passed to addShape would override that. The cascade would be: base style => GeoJSON object style => addShape style. A developer can keep the style property on the object even when it's stored, such as in GeoCouch, something that Guido wants a lot.
That said, I know I'm going about this wrong. As I said, my initial implementation feels too much like the old one and I want to do something much slicker in the jQuery world. On my walk home, I realized that since I am only storing a reference to the GeoJSON object and the user supplied style I can probably connect the style object to the GeoJSON object using jQuery's data method.
I wasn't sure if targeting a plain object is allowed in jQuery. I know it's possible but that doesn't mean I should. I remember IRC talk about it but forget the outcome. Info on ticket 8108 ( reveals that the DataLink plugin does this so I'm going to assume it's ok.
This little fiddle shows that the data properties don't show up with stringify but I'm going to do more research to see if it changes the object in a way devs will notice.
The data method doesn't natively support namespacing. I could do it myself using a period but I would like to follow what jQuery Mobile is doing with their data attribute stuff. They use data-jm-role which I believe equates to the call .data("jmRole") but I need to check up on that as well. So if I were to do data-geo-style, that would be .data("geoStyle"). I can live with that.
SUGGESTION: Store $.geo styles via $(geoJsonObj).data("geoStyle", style)
=== On shape functions ===
Again, the shape functions feel very old and were grabbed from my internal control. Tonight I was thinking about a new way to do this and it involves being able to wrap GeoJSON objects with jQuery collections and intercept $.fn calls such as .css. Also, non-jQuery UI functions can be added to the geomap widget's div to replace the old addShape method.
For example: $("#map").geomap("addShape", geoJson) could be $("#map").append(geoJson).
How would I add shapes to specific services in the future? $("#map [data-geo-service='OSM']").append(geoJson) maybe.
This might be going too far. Perhaps the old way is fine but use newer names (without the Shape suffix): $("#map").geomap("append", geoJsonObj), $("#map").geomap("append", "OSM", geoJsonObj), $("#map").geomap("remove", geoJsonObj) and $("#map").geomap("empty").
SUGGESTION: Rename the shape manipulation methods
The methods also need to take arrays of GeoJSON objects as returned by databases and jQuery collections of GeoJSON objects as possibly returned by the find method.
SUGGESTION: Shape manipulation methods should handle arrays
Looking back at the above code, I feel like maybe if I really can get the selector-based way to work, e.g., intercept the append call on the geomap widget, I could target the services using a class. They are divs inside the map, I should be able to trap them:
$("#map .OSM").append(geoJsonObj);
That does look really nice.
SUGGESTION: (future) Trap existing jQuery calls: append, remove and emtpy, on both the widget element and the service elements as syntactic sugar, forward them to geomap calls
However, using the class selector feels wrong. Especially if I'm telling them to use the id property when creating the service objects. I could switch it to name when creating the service objects, then:
$("#map [name='OSM']").append(geoJsonObj);
I need to find out if any of this is possible as soon as possible. It's still shorter than calling geomap. I would have to warn users to make sure the space is there, this needs to be a descendant selector.
SUGGESTION: Use name instead of id in the service objects.
=== On finding shapes ===
So you can append and remove shapes. Fine. But I also want a better way to search for shapes. Chris and I mulled over a selector-based way. I think I still want the simplicity of $("#map").geomap("find", position, pixelTol). That will cover a lot of use cases, users click maps a lot.
However, there should be other ways to get at your shapes in a UI widget way:
$("#map").geomap("find", [-67, 43], 8); // find all shapes within 8px of the map position (special case)
$("#map").geomap("find", "[type='Point']"); // Finds all points
$("#map").geomap("find", "[name='OSM'] *"); // all shapes in the OSM service (future)
$("#map").geomap("find", ":intersects(wkt(POINT(-67 43)))"); // Advanced spatial filter, OGC selector names (way future)
Here's how they would look with the future jQuery syntactic sugar:
$("#map").find([-67, 43], 8); // find all shapes within 8px of the map position (special case)
$("#map").find("[type='Point']"); // Finds all points
$("#map [name='OSM']").find(); // all shapes in the OSM service (future)
$("#map").find(":intersects(wkt(POINT(-67 43)))"); // Advanced spatial filter, OGC selector names (way future)
Jump to Line
Something went wrong with that request. Please try again.