Upgrade for Maps v3 API

[GoogleCodeExporter]

Are there any plans to upgrade this extension to be compatible with Maps API V3?

Original issue reported on code.google.com by ljkes...@gmail.com on 9 Sep 2010 at 5:30

[GoogleCodeExporter]

Yes I would like to and do have personal use for it in that context (which is 
frequently a determinant in whether something gets done on independent projects 
like this).

Original comment by lanceala...@gmail.com on 11 Sep 2010 at 12:16

• Added labels: Type-Task
• Removed labels: Type-Defect

[GoogleCodeExporter]

Is there any status on this?
I would be willing to help.

  -- Larry

Original comment by geocodezip on 3 Jan 2011 at 4:49

[GoogleCodeExporter]

Also looking forward to this. Any news?

Original comment by robinpel...@gmail.com on 26 Jan 2011 at 8:40

[GoogleCodeExporter]

Bump... any update?

Original comment by DeepBhar...@gmail.com on 2 Feb 2011 at 12:30

[GoogleCodeExporter]

I tried to email Lance directly to offer a quick port to v3 with no response.  
I hate to spend the time if it is already a work in progress.

  -- Larry

Original comment by geocodezip on 2 Feb 2011 at 3:53

[GoogleCodeExporter]

This will add great features to API v3 so I hope something will be done 
soon...just a status update will be enough for now... 

Original comment by DeepBhar...@gmail.com on 3 Feb 2011 at 4:46

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I've been playing with geoxml3 and have found it to be pretty solid.  There is 
not feature parity between the projects, i.e. the sidebar.  That said, it does 
a good job of parsing KML and building the Google maps overlays.  Support for 
polygons / polyline etc. is in a branch at the moment but I've been using that 
just fine.  

Original comment by r...@relativity.org on 9 Feb 2011 at 4:48

[GoogleCodeExporter]

hi
I start to migrate all my script to V3 api and ...
it is some news for the Upgrade geoxml  for  the API version 3 ?

Thank You

Original comment by jip...@gmail.com on 4 Jun 2011 at 7:19

[GoogleCodeExporter]

According to this message by Lance, he is almost done:
http://groups.google.com/group/google-maps-js-api-v3/msg/841d64de8d1e2900

Original comment by geocodezip on 16 Oct 2011 at 8:13

[GoogleCodeExporter]

geoxmlv3.js is indeed on its way (may be emailing folk to test it soon) 
currently written to use jquery.

Original comment by lanceala...@gmail.com on 26 Oct 2011 at 7:56

[GoogleCodeExporter]

I have checked this in such as it is 
http://geoxml.googlecode.com/svn/trunk/geoxmlv3.js

requires a recent jquery (for instance 1.6.4)
http://www.microimages.com/webmap/jquery-1.6.4.min.js

Many features untested a few known not implemented such as wms layers.

Basically letting those most interested get a pre-run at it.

Original comment by lanceala...@gmail.com on 28 Oct 2011 at 5:57

[GoogleCodeExporter]

Original comment by lanceala...@gmail.com on 28 Oct 2011 at 5:58

• Changed state: Started

[GoogleCodeExporter]

Most options and syntax are identical for v3.
Will start posting examples later.

Original comment by lanceala...@gmail.com on 28 Oct 2011 at 6:00

[GoogleCodeExporter]

Hello Lance,

If tested the new versionand I found some bugs. I changed the following lines:
- 3561  if(!!!bounds && map){
=> if(!!!bounds && overlaymanager.map){

- 3563  bounds = map.getBounds();
=> bounds = overlaymanager.map.getBounds();

Regards Mike

Original comment by mikesa...@gmail.com on 29 Oct 2011 at 9:13

[GoogleCodeExporter]

Thanks ... thats right I have been using a global var for the map... (I
wouldnt have noticed that).

Original comment by lanceala...@gmail.com on 30 Oct 2011 at 4:06

[GoogleCodeExporter]

I wanted to mention this version has support for marker <scale>

I should probably rename the class... Its probably more than a
bit confusing in its currentform.

Original comment by lanceala...@gmail.com on 30 Oct 2011 at 4:26

[GoogleCodeExporter]

Should we make issues if we find bugs for this version or do you want the 
problems in this issue?

I've found the following problems:
- The markers stay hidden after zooming or panning away and later back to their 
location
3768 marker.setMap(this.map);
=> marker.setMap(overlaymanager.map);
- The polyline are very small and almost not noticeable. Google maps version 3 
has changed something in the width.
702     if(!width){p.width = 2;}
=>      if(!width){p.width = 4;}

Regards Mike

Original comment by mikesa...@gmail.com on 30 Oct 2011 at 8:28

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Another strange piece of code is:

1577 var currdeschead = "";

Should this not be in the function GeoXml.prototype.makeDescription?
Now it's defined global and if there are multiple geoxml's on the same page 
they can conflict with each other.

Original comment by mikesa...@gmail.com on 30 Oct 2011 at 12:37

[GoogleCodeExporter]

3398    map.fitBounds(bounds);
=>  this.map.fitBounds(bounds);

Original comment by mikesa...@gmail.com on 30 Oct 2011 at 1:07

[GoogleCodeExporter]

I think the line width 4 looks clunky mostly a cosmetic thing but it occurred 
to me that is just a default and appropriate to match maps.google.com... so I 
think I will restore it anyway.

Original comment by lanceala...@gmail.com on 31 Oct 2011 at 1:35

[GoogleCodeExporter]

Hello Lance,

No problem on the polyline.

I see a different default (color and weigth) at maps.google.com, but it maybe 
depends on the example (florida.kml).

I've now a version without jquery. Are you interested?

Regards Mike

Original comment by mikesa...@gmail.com on 31 Oct 2011 at 9:13

[GoogleCodeExporter]

sure the plan is to divorce it from jquery we are only using a couple methods.. 
I believe the text method and parseXML method 

Original comment by lanceala...@gmail.com on 1 Nov 2011 at 2:30

[GoogleCodeExporter]

Attached the version with jquery.

Old parseXML commented, can be removed and use parseXML of jsQuery.
Rename $(..).text() to use function gettext same as jsQuery.

Original comment by mikesa...@gmail.com on 1 Nov 2011 at 5:40

Attachments:

• geoxmlfull_v3.js

[GoogleCodeExporter]

The old parseXml method on GeoXml was a utility method which allowed me to 
start with an xml object similar to parseString allowed one to start with a 
string. I may rename it to be processXml or remove it entirely depending on 
whether I confirm I still have a use for it.

Original comment by lanceala...@gmail.com on 2 Nov 2011 at 1:22

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

we might want to use the geoxml message box for errors
 or if console is defined... kind of like this.

console.log("Invalid XML found :"+data);

At least if somebody has firebug installed or using safari or chrome its better 
perhaps than an alert.

Original comment by lanceala...@gmail.com on 2 Nov 2011 at 7:42

[GoogleCodeExporter]

I agree on the good idea of console.log

Original comment by mikesa...@gmail.com on 2 Nov 2011 at 9:53

[GoogleCodeExporter]

Wanted to mention I've started testing the last version included in this thread 
(geoxmlfull_v3.js (Nov. 1, 2011) and had a couple difficulties getting it up 
and running. Now that it is, I must say it is working very well! I am really 
impressed how quick it runs with Gmaps v3. I'm testing with a 1 Mb+ KML. The 
only issue I've run into so far is how multigeometry polygons seem to be split 
out in the sidebar. I thought they were grouped together in the previous 
version (v2). I may be missing an option; I will investigate further, so no 
response is necessary. Just wanted to say that you guys are doing a great job!

Original comment by zephyrun...@gmail.com on 12 Nov 2011 at 8:23

[GoogleCodeExporter]

Hmmm I will have to investigate mulitpolygons - do you have a sample to look at?

Part of the reason for the increased speed is less processing is required in v3 
of the api.

By the way I have been doing some interesting things with tiled kml to enable 
large kml sources.

Original comment by lanceala...@gmail.com on 12 Nov 2011 at 9:20

[GoogleCodeExporter]

After toying around a bit more, I found the features do not get split up if I 
just remove the multigeometry tag. Here is a link that kinda explains what I am 
talking about (the feature name that I toy with is Nine Mile): 
http://zephyrdev.com/testing-public/GeoXmlv3-test/
I also added a point just to see what would happen. It doesn't seem to like it. 
I can't remember if this worked or not with v2. Most likely because I never mix 
points and polygons together like that. If you don't have time, I could try and 
see why this happens. 

"By the way I have been doing some interesting things with tiled kml to enable 
large kml sources."

I'm definitely interested in ways to handle big data more effectively! I'm 
already using GeoXml for this reason. 

Original comment by zephyrun...@gmail.com on 14 Nov 2011 at 11:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Is it correct NetworkLink is not yet fully implemened in v3?

My kml's:
    <Link>
        <href>/kml.php</href>
        <refreshMode>onChange</refreshMode>
        <viewRefreshMode>onStop</viewRefreshMode>
        <viewFormat>bbox=[bboxWest],[bboxSouth],[bboxEast],[bboxNorth]</viewFormat>
    </Link>

Viewformat, refreshmode are ignored (by looking at what kml it tries to fetch 
and on what event).

Yvo

Original comment by ymsch...@gmail.com on 18 Nov 2011 at 11:49

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Network Links can be pretty esoteric and were only implimented to a lesser 
degree in GeoXml, I did it primarily for a google maps network link. Some modes 
seem to make a whole lot less sense in a 2D gmaps environment other features 
like the bbox if the images are from WMS servers are better handled a different 
way. (But I specifically want ViewFormat elements for certain RSS feeds so to 
be worked on as time allows.)

Googles own parser wasnt too great with network links at one point though its 
been improved greatly.

It has been a while since I worked on GeoXml in a focused way now that I can do 
more it doesnt hurt to have things mentioned that you are interested in.

Original comment by lanceala...@gmail.com on 19 Nov 2011 at 1:34

[GoogleCodeExporter]

Hello Lance,

I had some time to look into the version 3 again. There is a problem with the 
infowindow. The title (h1) is not shown.

I've found the cause, the <div> in line 396 is not closed so the h1 tag is not 
displayed.
So this has to be closed before line 400 or on line 429 and in all other 
html1/2/3/4 variables.

My opinion is that the div with the calculated width is not necessary any more. 
I removed the div in my version.

Regards Mike

Original comment by mikesa...@gmail.com on 9 Dec 2011 at 10:04

Attachments:

• geoxmlfull_v3.js

[GoogleCodeExporter]

I also have some fixes that make the support of scale work better.

Original comment by lanceala...@gmail.com on 20 Dec 2011 at 1:27

[GoogleCodeExporter]

You may be right about not needing the preset width as much as we did in v2. 
But I have  some things which assume that is settable.... might have to allow a 
autocomputewidth option.

Original comment by lanceala...@gmail.com on 20 Dec 2011 at 1:38

[GoogleCodeExporter]

Hello Lance,

I found the problem with the polylines. The attributes of the style are changed 
by name:
            width = style.width; 
            color = style.color; 
            opacity = style.opacity; 
Should be:
            width = style.strokeWeight; 
            color = style.strokeColor; 
            opacity = style.strokeOpacity; 

Around lines 1925 and 2345.

Kind regards,

Mike

Original comment by mikesa...@gmail.com on 26 Dec 2011 at 9:01

[GoogleCodeExporter]

Hello Lance,

Solved another problem with the infowindow with directions.

To change the contents of an infowindow you should ot create a new infowindow 
but use:
m.infoWindow.setOptions(infoWindowOptions);

Second to have the original contents you need to give the back link a own event 
handler (click1) and change it back to html1

Third there is a mistake with the back link, a double quote is missing after # 
in it's href attribute.

Attached the version I created to solve this problems.

Kind regards

Mike

Original comment by mikesa...@gmail.com on 26 Dec 2011 at 9:55

Attachments:

• geoxmlfull_v3.js

[GoogleCodeExporter]

Thanks a lot for the help Mike the directions functions arent something I use 
much easy to overlook.

Original comment by lanceala...@gmail.com on 28 Dec 2011 at 3:55

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Need to get some sample pages up for testing with.

Original comment by lanceala...@gmail.com on 28 Dec 2011 at 11:53

[GoogleCodeExporter]

Options I am adding 
overrideOpacity, and suppresslinks and forcefoldersclosed.

Any ideas of improvements? Please let me know.

Original comment by lanceala...@gmail.com on 29 Dec 2011 at 4:40

[GoogleCodeExporter]

Reporting errors for the _v3 version in this thread is harder to track so I am 
thinking
I will start a new project for geoxml_v3

Original comment by lanceala...@gmail.com on 29 Dec 2011 at 9:24

[GoogleCodeExporter]

You're welcome.

I agree that we should create issues for geoxml v3 from now, because the bases 
is all right.
I'll setup some example pages myself based on v2 so I can test it.

I still have problems with:
* georss, but this could be a general error for v2 and v3.
* gpx files, works in v2 but loads forever in v3 and crashes my browser.

but I need to test more examples.

Regards Mike

Original comment by mikesa...@gmail.com on 30 Dec 2011 at 9:37

[GoogleCodeExporter]

I will get the new project base populated this evening.
And post the path to it here then (probably add a link
off this projects home page too

Original comment by lanceala...@gmail.com on 30 Dec 2011 at 5:26

[GoogleCodeExporter]

The new project for the google maps api version 3 is now located here.

http://code.google.com/p/geoxml-v3/

Mike email me if you would like to be added as a committer or something on the 
project.

Original comment by lanceala...@gmail.com on 31 Dec 2011 at 3:15