Fixed
Status Update
Comments
en...@gmail.com <en...@gmail.com> #2
The iPhone Simulator has a nice UI for this. You hold down a key combo and you see
two finger spots on the emulator screen, mirrored around the center of the screen.
Drag away from the center to pinch open; drag toward the center to pinch closed.
two finger spots on the emulator screen, mirrored around the center of the screen.
Drag away from the center to pinch open; drag toward the center to pinch closed.
ri...@gmail.com <ri...@gmail.com> #3
That is nice, but that only handles the case of "pinch". It would be a good start,
and would handle probably the majority of common use cases, but there are certainly
very many ways I can move two fingers at once that don't even resemble a pinch. :)
and would handle probably the majority of common use cases, but there are certainly
very many ways I can move two fingers at once that don't even resemble a pinch. :)
rm...@gmail.com <rm...@gmail.com> #5
This would be really handy. I would also like to mention that many people with TUIO devices would love to use them to test.
di...@gmail.com <di...@gmail.com> #6
Pinch is by far the most common multi-touch gesture IMHO. Also, the iPhone simulator also simulates two-fingered scrolling (dragging across the screen with two fingers). I can't think of any other two-fingered gesture that would make sense in a UI :)
Currently the Android version of our app is on hold because it uses multi-touch and we don't have an actual device to test it on.
Currently the Android version of our app is on hold because it uses multi-touch and we don't have an actual device to test it on.
ko...@gmail.com <ko...@gmail.com> #7
Rotation is another useful gesture.
Whatever the "common gestures" are, it would be nice to be able to hold down certain keys on the keyboard to perform these gestures in the emulator. E.g. Ctrl for pinch, Alt for Rotate, etc.
In addition, I would like to be able to move additional pointers freely. It could work by holding down number keys, for instance. Holding/pressing "1" would freeze all current pointers and let you control the first pointer with the mouse (up/down/move). Holding/pressing "2" would freeze all current pointers and let you control the second pointer (up/down/move). Etc. This would be useful for apps that use actual multitouch and not just gestures.
Whatever the "common gestures" are, it would be nice to be able to hold down certain keys on the keyboard to perform these gestures in the emulator. E.g. Ctrl for pinch, Alt for Rotate, etc.
In addition, I would like to be able to move additional pointers freely. It could work by holding down number keys, for instance. Holding/pressing "1" would freeze all current pointers and let you control the first pointer with the mouse (up/down/move). Holding/pressing "2" would freeze all current pointers and let you control the second pointer (up/down/move). Etc. This would be useful for apps that use actual multitouch and not just gestures.
lu...@google.com <lu...@google.com>
fa...@gmail.com <fa...@gmail.com> #10
With TUIO support, we could use the TUIO Simulator for testing Multi-Touch. I used that tool to develop a tabletop Application.
But a solution which is integrated into the android simulator would be much more handy.
But a solution which is integrated into the android simulator would be much more handy.
je...@gmail.com <je...@gmail.com> #12
I'm thinking of a way to develop an application that you can run on your android phone, connect the phone via usb and have the emulator redirect the input form the phone to the virtual device. This way you can test multi-touch inside the emulator using a real device. I've no idea of the applicability of this solution, and whether there's something like that already implemented, so comments and guidance would be appreciated :)
pe...@gmail.com <pe...@gmail.com> #13
To #11, that would be a nice idea, but you have to keep in mind there are very different screen sizes and formats and doing letterboxing to, say, map a 16:9 real screen to a 4:3 or 1:1 screen might not be ideal.
Still, it's a nice idea to work around this while the emulator doesn't have direct support, IMHO.
Still, it's a nice idea to work around this while the emulator doesn't have direct support, IMHO.
re...@gmail.com <re...@gmail.com> #14
[Comment deleted]
je...@gmail.com <je...@gmail.com> #15
This feature is especially important since multitouch has been enabled since 2.0.
Even considering how bad Eclipse is, the emulator is the worst part of the SDK. It's slow. Try the iOS Simulator is relatively fast and doesn't take a minute to launch.
Even considering how bad Eclipse is, the emulator is the worst part of the SDK. It's slow. Try the iOS Simulator is relatively fast and doesn't take a minute to launch.
go...@gmail.com <go...@gmail.com> #16
To be fair, the Android emulator is a legitimate phone emulator. Almost _anything_ you can do with a real phone can be successfully tested in the emulator (save for multitouch, obviously, but that's an interface issue, not a software issue). It really is emulating the ARM processor, which is what makes it slow. The iPhone simulator does not actually emulate anything. The "simulator" label is very appropriate, because it only simulates enough of iOS to run a version of your application (not necessarily the final compiled version that will run on the phone), so you can't really say for sure that "works in the simulator, works on the phone" like you can with Android's emulator. Closer to it's original release, there were even a couple guys who hooked up GPS and an accelerometer to the emulator and used their laptop to test the app they'd developed before we had any physical phones, which is something the iPhone simulator couldn't even dream of.
Not to downplay the need for multitouch, but need to give props to the emulator folks where props are due, because they've done some seriously cool work.
Not to downplay the need for multitouch, but need to give props to the emulator folks where props are due, because they've done some seriously cool work.
[Deleted User] <[Deleted User]> #17
Any official word from Google on this? Apart from making the SDK faster, this is second on my wish list. It's more than I nice-to-have. You can't seriously test anything multitouch-related without an actual device, which is a pretty big drawback.
Also, to clarify another comment above: you can do more than multitouch scale (pinch-to-zoom) in the iOS simulator. You can also rotate elements. It's not as natural as it would be on an actual device, but it's passable. Right now it's completely impossible in the Android emulator, save for actually simulating the events in JavaScript.
Also, to clarify another comment above: you can do more than multitouch scale (pinch-to-zoom) in the iOS simulator. You can also rotate elements. It's not as natural as it would be on an actual device, but it's passable. Right now it's completely impossible in the Android emulator, save for actually simulating the events in JavaScript.
rk...@gmail.com <rk...@gmail.com> #18
Google doesn't comment on (or read) bug reports in this issue tracker.
This issue is in the status "New", which means that no Googler has reviewed the issue. Unfortunately, it's not alone; 80% of the top 100 Defects are "New."
http://code.google.com/p/android/issues/list?q=Type%3ADefect&sort=-stars
And it's even worse when you look at the top 100 enhancements, all of which have more stars than this issue.
http://code.google.com/p/android/issues/list?q=Type%3AEnhancement&sort=-stars
This issue is in the status "New", which means that no Googler has reviewed the issue. Unfortunately, it's not alone; 80% of the top 100 Defects are "New."
And it's even worse when you look at the top 100 enhancements, all of which have more stars than this issue.
rg...@gmail.com <rg...@gmail.com> #19
Well, in r17 they've finally added "Multi-Touch" support, as detailed here: http://tools.android.com/tips/hardware-emulation#TOC-Multi-Touch
However, to use this multitouch support requires a phone tethered running their multi-touch simulation software, so it's still limited to folks owning a real phone, in which case you might as well test directly on the phone.
However, to use this multitouch support requires a phone tethered running their multi-touch simulation software, so it's still limited to folks owning a real phone, in which case you might as well test directly on the phone.
he...@gmail.com <he...@gmail.com> #20
Hi there,
the online documentation is not up to date
see
http://code.google.com/p/android/issues/detail?id=34868
use the instruction you find in the SdkController application itself.
the online documentation is not up to date
see
use the instruction you find in the SdkController application itself.
[Deleted User] <[Deleted User]> #21
I'd like to see this feature implemented not so much because I don't have a device, but because sometimes I would like to:
1) Test multi-touch with different Android versions,
2) Develop on a remote desktop (hence no possibility to attach a physical device).
1) Test multi-touch with different Android versions,
2) Develop on a remote desktop (hence no possibility to attach a physical device).
he...@gmail.com <he...@gmail.com> #22
[Comment deleted]
th...@google.com <th...@google.com> #23
[Comment deleted]
mf...@gmail.com <mf...@gmail.com> #24
[Comment deleted]
he...@gmail.com <he...@gmail.com> #25
I've solved the matter by rewriting all my code. Instead of linemarkers everywhere like in enabledrawing in V2, which slows down fe IE enormous, I build up a path. Each path gets a draggable marker at the end. This path can be split when it is made from data imported from gps devices, changed to straight lines or use routing. Routing can be inserted everywhere even at km 10 when you disigned 100 kms. This works realy fast and is more logic for the user. However it took a lot of time to make it.
da...@gmail.com <da...@gmail.com> #26
Implemented by CL 185430
lu...@gmail.com <lu...@gmail.com> #27
Specifically, a pinch/rotate gesture was added in Emulator release 25.0.4 preview 5 - hold Alt to bring up the interface.
Reference issue 36949180 to track the addition of a "two-finger swipe gesture".
Reference issue 36949180 to track the addition of an interface for general multitouch input.
Reference
Reference
ra...@gmail.com <ra...@gmail.com> #28
need this too!
br...@gmail.com <br...@gmail.com> #29
Another vote for this!!!!
gr...@gmail.com <gr...@gmail.com> #30
We started to migrate scripts from deprecated V2 to v3 until we realize that this important fetaure is missing... So unfortunately we have to remain in V2 until a similar tool is available
we...@gmail.com <we...@gmail.com> #31
je...@gmail.com <je...@gmail.com> #32
great job!
ar...@gmail.com <ar...@gmail.com> #33
Not for me: I really need to be able to edit the polygons afterwards, add points halfway, etc.
br...@gmail.com <br...@gmail.com> #34
ooow,
get back with this featuure, why remove then ?
get back with this featuure, why remove then ?
vi...@gmail.com <vi...@gmail.com> #35
Google dudes, this is important, not superfluous.
People want to add their own geographic information to their communities.
People want to add their own geographic information to their communities.
di...@gmail.com <di...@gmail.com> #37
may someone give a hint on how the circle of dragging directions is centered on the "svg-polyline stroke-area"?
Also, how the z-index of the google.maps.Marker must be modified (with respect to google.maps.Polyline object) in order to avoid leaving the svg-polyline when the mouse "hover" over the "circle"? This happens if the mouse is moving toward the top corner of a vertical line.
Also, how the z-index of the google.maps.Marker must be modified (with respect to google.maps.Polyline object) in order to avoid leaving the svg-polyline when the mouse "hover" over the "circle"? This happens if the mouse is moving toward the top corner of a vertical line.
je...@gmail.com <je...@gmail.com> #38
Is there any way to know if google has planned to include this feature in the next versions?
Regards.
Regards.
ga...@itrak.com <ga...@itrak.com> #40
I am another that cannot move to V3 until this capability is added back in. Our application requires that users have the Drawing and Editing functionality. Meanwhile I will look at a workaround.
da...@gmail.com <da...@gmail.com> #41
would really like to see this feature too. V3 has been around for a long time and it is a key feature for a number of our customers. having to switch between v2 and v3 is a real pain and end users have a bad experience as the maps behave differently
pr...@gmail.com <pr...@gmail.com> #42
I would really like to see this feature in v3
vi...@gmail.com <vi...@gmail.com> #43
This is absolutely essential for my app(s) also. Had to move to the deprecated v2 API jst because of this missing functionality... :(
ri...@gmail.com <ri...@gmail.com> #44
vi...@gmail.com <vi...@gmail.com> #45
Hi riccco,
I think the google licensing prevents us from using google basemaps in OpenLayers...
Thank You,
Vish
I think the google licensing prevents us from using google basemaps in OpenLayers...
Thank You,
Vish
ri...@gmail.com <ri...@gmail.com> #46
i will have a look at this question. thanks a lot for pointing this out Vish
But i wonder why it could be possible to use google with mapstraction and not with openlayers.
Maybe the dev team could give a response
Best regards
riccco
But i wonder why it could be possible to use google with mapstraction and not with openlayers.
Maybe the dev team could give a response
Best regards
riccco
cr...@gmail.com <cr...@gmail.com> #47
Please add editing, minimally like you can with google "my maps".
si...@inbox.ru <si...@inbox.ru> #48
i really want this tool too
sa...@gmail.com <sa...@gmail.com> #49
I would really like to see this feature in v3
kr...@gmail.com <kr...@gmail.com> #50
this is wery important, we cant upgrade to v3 if there is no editing
zy...@gmail.com <zy...@gmail.com> #51
this is wery important, please add drawing / editing
sc...@gmail.com <sc...@gmail.com> #52
My application need enableDrawing and enableEditing features! Please add it to V3!
Emulating this features is not very fast and comfortable ((
Emulating this features is not very fast and comfortable ((
da...@gmail.com <da...@gmail.com> #53
@Google
Any further info on whether this will/ won't be ported over to API3?
Can the Google Maps community help out with this:
Are you able to post the relevant API2 functions so we can have a go migrating the code?
Any further info on whether this will/ won't be ported over to API3?
Can the Google Maps community help out with this:
Are you able to post the relevant API2 functions so we can have a go migrating the code?
th...@google.com <th...@google.com> #54
Yes, we are working on this. Currently aiming for a Q1 release.
da...@gmail.com <da...@gmail.com> #55
Made my day...
Look forward to seeing it. Thanks!
Look forward to seeing it. Thanks!
jo...@aafa-inc.com <jo...@aafa-inc.com> #56
I waited and waited. Finally made my own last week.
But still, thanks for listening. And will use the new feature when it releases.
But still, thanks for listening. And will use the new feature when it releases.
ar...@gmail.com <ar...@gmail.com> #57
Can any of the developers provide any kind of estimation about when this will be ready? I mean something else rather than within this Q1. Because if it is by the end of Q1 then it may be too late for me :-(
Cheers for the good work.
Cheers for the good work.
de...@gtempaccount.com <de...@gtempaccount.com> #58
I agree.. I have spent the last few days trying to figure this out to no avail.. I see google My Maps drawings tools doing what I was doing in v2 but after some digging, I found that even My Maps is using v2! Auto-close feature is nice but when you try to put a point that is inside of the polygon it is automatically set as a polygon click instead of a new point. Makes it hard to stop editing, then pull up an infowindow to capture data.
kw...@gmail.com <kw...@gmail.com> #59
Yes - I'd like that too. I can see how to write it myself, but it would be a very nice feature to have available.
Obviously, it'd need to be switchable, so I can switch on and off editing as required.
Obviously, it'd need to be switchable, so I can switch on and off editing as required.
xi...@gmail.com <xi...@gmail.com> #60
This is a huge feature that we have incorporated in the past with V2. We recently began upgrading all of our Maps to V3 and have lost this functionality in the upgrade.
I appreciate your work Google, please add these to V3!
I appreciate your work Google, please add these to V3!
lo...@gmail.com <lo...@gmail.com> #61
If it is not asking much, could you offer similar user experience than when dragging routes? I have attached a quick screen capture of our current implementation on V3 API.
dp...@gmail.com <dp...@gmail.com> #62
we need this tool
yo...@gmail.com <yo...@gmail.com> #63
Rumour has it that polygon/polyline editing is due to return in Q1 of 2011.
Hope this is true, as one of our apps makes heavy use of polygon editing. Our v2 to v3 migration plans are currently in limbo whilst we don't have polygon editing.
Hope this is true, as one of our apps makes heavy use of polygon editing. Our v2 to v3 migration plans are currently in limbo whilst we don't have polygon editing.
th...@google.com <th...@google.com> #64
Being the person who started that rumour I can confirm that we are continuing to work on this, but the scheduled has now slipped a little to mid Q2. Apologies for the delay.
yo...@gmail.com <yo...@gmail.com> #65
Thanks for the update, will look forward to hearing about "the return of polygon editing" in mid/late Q2
jk...@gmail.com <jk...@gmail.com> #66
Another vote for this!
ks...@gmail.com <ks...@gmail.com> #67
without enableEditing and enableDrawing i gotta stay with API v2... i really need this features and i don't have time to implement this myself. This was a mayor reason why i even used google maps for that purpose. So please get that features back!
Ga...@gtempaccount.com <Ga...@gtempaccount.com> #68
Like many others, the lack of line/polygon editing is blocking our move to v3 for an Enterprise customer.
da...@gmail.com <da...@gmail.com> #69
@Google
Are you able to provide any feedback on what layer the interactive polylines will be drawn in?
If it's the MapPanes.overlayLayer, is it possible to have an extra option to allow the interactive lines to always be visible by drawing them above the layers for polygons/ polylines/ markers/ images (eg interactive end-user activity visible at a higher layer?
(This other benefit is it would provide even greater flexibility to custom google.maps.OverlayView rendering)
Are you able to provide any feedback on what layer the interactive polylines will be drawn in?
If it's the MapPanes.overlayLayer, is it possible to have an extra option to allow the interactive lines to always be visible by drawing them above the layers for polygons/ polylines/ markers/ images (eg interactive end-user activity visible at a higher layer?
(This other benefit is it would provide even greater flexibility to custom google.maps.OverlayView rendering)
sc...@gmail.com <sc...@gmail.com> #70
Just started working with the API. Had started with V3, but ended up using V2 because of this issue. Would really like to move to V3 since it also has features I could take advantage of, I will be looking forward to having this implemented into the latest version.
cd...@gmail.com <cd...@gmail.com> #71
Intensely critical feature. I have multiple applications dependent on Poly editing and creation. And it pains me to see all the possibilities with Fusion Tables in v3 that v2 lacks. So please add Poly editing support to v3. Please also support Poly encoding, as my applications are dependent on that as well.
sp...@gmail.com <sp...@gmail.com> #72
@73 - Polyline encoding is a different issue, and can be considered done due to the existence of the function in the google.maps.geometry.encoding namespace.
on...@gmail.com <on...@gmail.com> #73
Polyline/polygon editing is crucial for my applications too. Would really like to see this feature in V3.
me...@gmail.com <me...@gmail.com> #74
Quote: Yes, we are working on this. Currently aiming for a Q1 release.
Now its Q3 and still no drawing :(
Now its Q3 and still no drawing :(
sc...@gmail.com <sc...@gmail.com> #75
So, please say : when the Drawing/Editing update will release?
We all waiting for it!
We all waiting for it!
th...@google.com <th...@google.com> #76
Can't deny that it is taking longer than we had expected, but this is still in the pipeline. Somewhat hesitant to commit precisely given how unsuccessful we have been at hitting our predicted dates so far, but right now we're aiming for mid quarter.
1i...@gmail.com <1i...@gmail.com> #77
Drawing and editing of polygon/polyline is a very impotent feature in GIS without it, it is really tuff to switch to V3. because in V2 we include this feature but now if we upgrade it to V3 as google says to do so, then we have to sacrifice one very impotent feature. which is really tuff for now.
Please let me know if you are introducing it shortly.
Please let me know if you are introducing it shortly.
ja...@gmail.com <ja...@gmail.com> #78
If you people are working on it, you could be honest about it in the docs: http://code.google.com/apis/maps/documentation/javascript/reference.html
It could include method name as red and note that this feature is not ready yet!
It could include method name as red and note that this feature is not ready yet!
pr...@gmail.com <pr...@gmail.com> #79
any idea when this feature will be released?
Ga...@gtempaccount.com <Ga...@gtempaccount.com> #80
"Mid-Q3" is now behind us, still no enableEditing or enableDrawing. Is there a way for Enterprise clients to weigh in here? I begin to be reluctant to recommend Enterprise if Google is not going to ever finish V3.
am...@gmail.com <am...@gmail.com> #81
Now we're in Q4 and there's no drawing available. Any update?
br...@stardothelp.com <br...@stardothelp.com> #82
The last comment from Google on this thread was in July. It feels like this has been forgotten about. Can we have an honest assesment from someone in the know on the project team. I've seen a couple of solutions knocking around but I'd rather wait if a shiny Google fix is going to be out soon.
yo...@gmail.com <yo...@gmail.com> #83
Hear, hear!
Oh mighty code lords of Google, please let us know if you still intend to bring back enabledrawing and enableediting. Even if you're not going to bring them back; please confirm the decision so that we can all start looking for ways to get on with our projects (and lives)...
Oh mighty code lords of Google, please let us know if you still intend to bring back enabledrawing and enableediting. Even if you're not going to bring them back; please confirm the decision so that we can all start looking for ways to get on with our projects (and lives)...
th...@google.com <th...@google.com> #84
Yes, we're absolutely still working on this. It's just proving to be more complex than we expected to get the UI right across all the different devices we support. Keep an eye on the Geo Developer Blog for a launch announcement later in the quarter.
gn...@gmail.com <gn...@gmail.com> #85
Google has their priorities guys, like shutting down aardvark.
me...@gmail.com <me...@gmail.com> #86
Oh come on, "different devices" isnt needed at all.
At least 90% of those who need drawing for polylines will need this for desktops and not mobile devices, so this could be added later to the UI couldnt it?
At least 90% of those who need drawing for polylines will need this for desktops and not mobile devices, so this could be added later to the UI couldnt it?
ar...@gmail.com <ar...@gmail.com> #87
"Oh come on, "different devices" isnt needed at all." +1
At least it should not have the same priority as the browser version.
At least it should not have the same priority as the browser version.
[Deleted User] <[Deleted User]> #88
This is the bug that never ends.
It just goes on and on my friends.
Some people... started following not knowing what it was,
And they'll continue following forever just because...
It just goes on and on my friends.
Some people... started following not knowing what it was,
And they'll continue following forever just because...
dj...@googlemail.com <dj...@googlemail.com> #89
We moved to Google Maps API Premier in March and are still using V2 because of the lack of support for enableDrawing and enableEditing. Don't care about mobile devices need this for the desktop.
am...@gmail.com <am...@gmail.com> #90
I guess that most of the people that are interested in this feature are coming from V2, and the only reason to move to V3 is to keep updated and because V2 is deprecated. Enable editing for mobile is not a priority for such situations.
In fact, after the feature is released it will still take a time for people to upgrade their integrations and release the new code to their users so it really makes sense to ship a function that brings parity with V2 and then later on add the mobile pieces. So by the time that we (external developers) put the upgraded maps on our sites you (Google) might have already added the mobile UI and there are no extra delays.
In fact, after the feature is released it will still take a time for people to upgrade their integrations and release the new code to their users so it really makes sense to ship a function that brings parity with V2 and then later on add the mobile pieces. So by the time that we (external developers) put the upgraded maps on our sites you (Google) might have already added the mobile UI and there are no extra delays.
ti...@gmail.com <ti...@gmail.com> #91
Seems like people just need to settle down a bit, honestly if you have been waiting for this since v3 came out, then there is no excuse not to have built your way around it, there are a few open source alternatives that are very near v2's functionality, and they are just the results of a 1 man effort.
If you have the money to push and purchase enterprise, then I am baffled that you are just sitting around and waiting, and that you cannot have a programmer pull together an editable polygon prototype which works solely on the pc environment.. you only need it to work for your application, not everything like the maps team does.
If you have the money to push and purchase enterprise, then I am baffled that you are just sitting around and waiting, and that you cannot have a programmer pull together an editable polygon prototype which works solely on the pc environment.. you only need it to work for your application, not everything like the maps team does.
cs...@hotmail.com <cs...@hotmail.com> #92
[Comment deleted]
cs...@hotmail.com <cs...@hotmail.com> #93
[Comment deleted]
cs...@hotmail.com <cs...@hotmail.com> #94
Please support drawnPolygon.enableEditing drawnPolygon.disableEditing gevent.addlistener(drawnPolygon, "endline", function(){}... ---and all this functionality that my small business has heavily integrated into our website and depends on. I feel like Google baited us into using this in v2 and is now stabbing us in the back by taking this functionality away.
ja...@gmail.com <ja...@gmail.com> #95
I need enable Editing too, so please support this.
fe...@gmail.com <fe...@gmail.com> #96
This tool it`s realy important, we need to v3 api support that.
ga...@gmail.com <ga...@gmail.com> #97
Take a look at the new polygon definition/editing tool on Trulia's real estate map ( www.trulia.com ). That's the type of functionality I want to see built in to the API.
lo...@gmail.com <lo...@gmail.com> #98
Please guys, avoid to write saying that you need it and it is very important for you. It does not help. I think this is a place to discuss possible features or ideas. The model proposed by #99 takes no more than 2 working days (I have done it in less time). As #93 suggested, if you cannot do it by yourself but you have a bit of money, this feature should not be a problem or a block for you.
ag...@gmail.com <ag...@gmail.com> #99
For anyone who want's this feature I've extended polygon class to enable editing... you can find it in http://code.google.com/p/anthill-maps/
sl...@gmail.com <sl...@gmail.com> #100
It appears the just released 3.7 version finally supports it (http://code.google.com/p/gmaps-api-issues/wiki/JavascriptMapsAPIv3Changelog ) but the documentation has not yet been updated.
Havent tried it yet, but someone has (http://code.google.com/apis/maps/documentation/javascript/forum.html?place=msg%2Fgoogle-maps-js-api-v3%2FSKd-HskNthQ%2Fn3LCY7WrONIJ )
Havent tried it yet, but someone has (
th...@google.com <th...@google.com> #101
Happy to say this we've now launched shape editing and drawing tools:
http://googlegeodevelopers.blogspot.com/2011/11/make-your-map-interactive-with-shape.html
Sorry it took so long. Please give it a try and log new feature requests for anything you would like to see added!
Sorry it took so long. Please give it a try and log new feature requests for anything you would like to see added!
yo...@gmail.com <yo...@gmail.com> #102
Haven't had a chance to play with this yet, but I would just like to say "thank you" to everyone involved in getting this feature released. I can now say "goodbye" to v2. Excellent!
lu...@gmail.com <lu...@gmail.com> #103
Hi... thanks for this feature, so long waited...
Do yo think add ability of this feature like Gmaps V2 enableEditing???? it's very dificult take the same result... please make think simple. Is very frustrating recreate all from scratch...
Do yo think add ability of this feature like Gmaps V2 enableEditing???? it's very dificult take the same result... please make think simple. Is very frustrating recreate all from scratch...
ge...@gmail.com <ge...@gmail.com> #104
thanks!
Description
enableEditing in V3 of the API.