KML export bounding box is incorrect when DD or DMS are used to define extent

[GoogleCodeExporter]

What steps will reproduce the problem?
1. In MORIS, add and zoom to a vector data layer (e.g., lighthouses). Launch 
the data export wizard by clicking the "Export data" tool. Click "Next" to go 
to Step 2.
2. In Step 2, open the "Advanced – Change area of interest" section, select 
"Decimal degrees" or "Deg min sec," and click "Import active map's bounding 
box." Click "Next" to go to Step 3. Make sure features are found within the 
extent and the data layer is okay to export. Click "Next" to go to Step 4. 
3. In Step 4, select "Keyhole Markup Language (.kml)" as the vector data 
output. Click "Next" to go to Step 5 and download the vector data layer. 4. 
Open the exported KML file with Google Earth. The output KML does not include 
any features.

What is the expected output? What do you see instead?
Features should be included in the KML, but instead it is empty and has no 
features.

Please use labels and text to provide additional information.
This bug was present in an earlier version of MORIS. It was addressed by 
forcing the final export URL to use the translated MA State Plane coordinates 
(EPSG 26986), while allowing the user to enter geographic lat/long coordinates 
at Step 2 of the wizard. It appears that this fix applies to shapefile data 
exports only. It needs to be applied to raster (see Issue 30) and KML data 
exports as well.

Tested MORIS v. 0.35 on Windows 7 and Firefox 5.0.

Current workaround: In Step 2 of the data export wizard, open the "Advanced – 
Change area of interest" section, select "MA State Plane meters," and click 
"Import active map's bounding box."

Original issue reported on code.google.com by emily.hu...@state.ma.us on 5 Jul 2011 at 8:30

[GoogleCodeExporter]

Original comment by emily.hu...@state.ma.us on 5 Jul 2011 at 8:33

• Added labels: Priority-High, Export
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Is this still an issue since (I think) everything is now being exported in MA 
planar?

Original comment by cpl...@gmail.com on 24 Aug 2011 at 8:17

[GoogleCodeExporter]

I tried KML with Lighthouses with and without the bbox change and both times I 
don't get a KML file.  See attached.

Original comment by Aleda.Fr...@state.ma.us on 25 Aug 2011 at 3:35

Attachments:

• no_kml.JPG

[GoogleCodeExporter]

Has anything changed server-side?  I can't seem to pull back a .kml via the 
production MORIS either.

Original comment by cpl...@gmail.com on 25 Aug 2011 at 6:29

[GoogleCodeExporter]

Can you tell me the request (URL, XML?) that is being use to grab the KML? 

Original comment by Aleda.Fr...@state.ma.us on 26 Aug 2011 at 5:45

[GoogleCodeExporter]

I thought Saul and I tested KML through OLIVER, so there might be a different 
type of request than this which I found in the GeoServer documentation: 

http://170.63.166.214/geoserver/wms/reflect?layers=massgis:GISDATA.TOWNS_POLY&fo
rmat=application/vnd.google-earth.kml+xml&styles=GISDATA.TOWNS_POLY::GreenOutlin
e - Works (internal GeoServer, no Gateway):

http://giswebservices.massgis.state.ma.us/geoserver/wms/reflect?layers=massgis:G
ISDATA.TOWNS_POLY&format=application/vnd.google-earth.kml+xml&styles=GISDATA.TOW
NS_POLY::GreenOutline - Gateway error

Original comment by Aleda.Fr...@state.ma.us on 26 Aug 2011 at 5:53

[GoogleCodeExporter]

I have a current (as in production) copy of MORIS on staging maps and I see 
that it generates a link such as this:

http://giswebservices.massgis.state.ma.us/geoserver/wms?layers=massgis:GISDATA.L
IGHTHOUSES_PT&service=WMS&version=1.1.0&request=GetMap&bbox=-75.17820119444445,3
9.982373555555554,-65.74070005555555,44.06761438888889&srs=EPSG:26986&height=100
&width=100&styles=&format=application/vnd.google-earth.kml+xml 

which does get past the Gateway, however it doesn't draw the data.

Also, I'm disturbed that we don't have any style info - did we never have that? 
Not always are we using the default style. 

Original comment by Aleda.Fr...@state.ma.us on 26 Aug 2011 at 5:59

[GoogleCodeExporter]

Actually, I think the point of this issue is that it works in OLIVER but not 
MORIS because of the units. 

Try with http://maps.massgis.state.ma.us/map_ol/oliver.php with Prisons (or 
Lighthouses, whatever) - it's fine. 

http://giswebservices.massgis.state.ma.us/geoserver/wms?layers=massgis:GISDATA.P
RISONS_PT&service=WMS&version=1.1.0&request=GetMap&bbox=-5114.445988,750375.3598
77,395314.500164,986169.74241&srs=EPSG:26986&height=100&width=100&styles=&format
=application/vnd.google-earth.kml+xml

I'm looking at the link, not zipping it up. Even in the current OLIVER if I use 
the zip file there is no KML file in the zip file, I don't think there ever 
was? But now, with the new Export there is no option to see individual links, 
only a .zip file so we'll have to get it in there.

Original comment by Aleda.Fr...@state.ma.us on 26 Aug 2011 at 6:07

[GoogleCodeExporter]

Now I'm really confused.  Does either production (old version) app export KML 
OK?

Original comment by cpl...@gmail.com on 26 Aug 2011 at 6:18

[GoogleCodeExporter]

Here's what I think and I could use Emily to help my brain.
Yes, the OLIVER app currently available to the public supports KML OK.
No, the MORIS pp currently available to the public does not support KML OK.
I thought that was the point of this issue.
(MORIS using a different basemap).

Neither OLIVER nor MORIS uses styles in the KML - I think they should.
For example, if I try to generate KML for LANDUSE_POLY and I want 1985 I really 
need the style info in the KML link which is not there.   Otherwise I get the 
default style which is incorrect here.  See the empty styles parameter:

http://wsgw.mass.gov/geoserver/wms?layers=massgis:GISDATA.LANDUSE_POLY&service=W
MS&version=1.1.0&request=GetMap&bbox=207847.874928,891455.279605,214584.849837,8
95422.377524&srs=EPSG:26986&height=100&width=100&styles=&format=application/vnd.
google-earth.kml+xml 

As a third point, the only way to get KML at the OLIVER app 
http://maps.massgis.state.ma.us is to use the link.  It doesn't go into the 
.zip file.  But in our development version we've taken away those links, so now 
we need to tuck a kml file into the .zip. 

Original comment by Aleda.Fr...@state.ma.us on 26 Aug 2011 at 6:31

[GoogleCodeExporter]

The public versions of MORIS and OLIVER export KMLS okay if the user selects MA 
state plane meters for the area of interest bounding box in the data export 
wizard. The exported KMLs have the wrong file extension though (see issue 35).

In v37, the exported KMLs still aren't being exported in MA state plane unless 
a user selects state plane meters for the area of interest bounding box 
coordinates.

Original comment by emily.hu...@state.ma.us on 26 Aug 2011 at 6:55

[GoogleCodeExporter]

I feel like we've fought this battle before . . .

I can see that I should get a .kml if I use srs=epsg:26986 as well as 26986 
bbox.

But no matter what I try, I can't pull .kml out if I do anything else, e.g. 
4326 bbox and 4326 epsg.

So can a user only export .kml in 26986 and only specify 26986 bbox?

Original comment by cpl...@gmail.com on 26 Aug 2011 at 7:49

[GoogleCodeExporter]

I don't know, maybe GeoServer only supports the native projection.  I thought 
the idea was to use 26986 anyway? 

Original comment by Aleda.Fr...@state.ma.us on 26 Aug 2011 at 8:19

[GoogleCodeExporter]

OK.  I'll force 26986 all the way around.  But my feeling is that KML in 26986 
isn't all that friendly.  Can't open it in GE.

Original comment by cpl...@gmail.com on 26 Aug 2011 at 8:34

[GoogleCodeExporter]

I'm confused now... Whatever you're doing that works in OLIVER 
maps.massgis.state.ma.us/map_ol/oliver.php - although it's named .tif - works 
and opens find in Google Earth - so can we do that for the MORIS?

Original comment by Aleda.Fr...@state.ma.us on 26 Aug 2011 at 8:42

[GoogleCodeExporter]

Praise the flying spaghetti monster.  I think we have a working export zip kml 
marriage now.

Both map.js and mkzip need to change.

If it's easier to change mkzip manually, look for the 1st instance of 'kml' and 
swap out that line for this one:

elsif (unsafeXML($h{baseURL}) =~ /application\/vnd.google-earth.kml\+xml/) {

This takes care of the .tif issue, too.

Committed revision 84.

Original comment by cpl...@gmail.com on 26 Aug 2011 at 8:58

[GoogleCodeExporter]

This works for me.  Firefox 6.  I tried a subset of colleges.

Original comment by Aleda.Fr...@state.ma.us on 8 Sep 2011 at 8:18

[GoogleCodeExporter]

Issue 35 has been merged into this issue.

Original comment by emily.hu...@state.ma.us on 26 Sep 2011 at 6:09

[GoogleCodeExporter]

I successfully downloaded a KML with the area of interest defined in decimal 
degrees and degrees minutes seconds.

The output KML now has the correct file extension, but it still isn't being 
named with its SDE name. For example, Lighthouses.kml should be named 
GISDATA_LIGHTHOUSES_PT.kml.

Aleda, should the styles apply to the output KMLs? For example, when I download 
the Boston Harbor Islands National Recreation Area, which is a subset of the 
National Park Service data layer, I get the full NPS dataset with its default 
symbology, not the Boston Harbor Island symbology.

Tested with Chrome 14 on Windows 7.

Original comment by emily.hu...@state.ma.us on 26 Sep 2011 at 6:21

[GoogleCodeExporter]

Charlton, I don't know what to give you for syntax, but this layer: 
massgis:MORIS.GEOREG_NPS_POLY  has a different "look" when this style is used:
MORIS.GEOREG_NPS_POLY::Boston_Harbor_Islands

When you generate the KML in the zip file you should have an option of 
specifying the style that goes with the layer.  If so, we'd like the style to 
be specified. Then, in the output kml the style info should be appropriate.

Original comment by Aleda.Fr...@state.ma.us on 28 Sep 2011 at 6:33

[GoogleCodeExporter]

Re. Comment 19 . . . "The output KML now has the correct file extension, but it 
still isn't being named with its SDE name. For example, Lighthouses.kml should 
be named GISDATA_LIGHTHOUSES_PT.kml."  This looks like it could be related to 
Issue 45, but 45 only asked for geotiff's to be renamed.  I went ahead and 
changed it for .kml's.  Aleda, you're going to have to update your mkzip.

Committed revision 166.

Original comment by cpl...@gmail.com on 7 Oct 2011 at 5:51

[GoogleCodeExporter]

Style is now being passed along to mkzip for kml layers.

v. 0.62
Committed revision 169.

Original comment by cpl...@gmail.com on 7 Oct 2011 at 6:30

• Changed state: Fixed

[GoogleCodeExporter]

Exported KMLs are now named with the SDE name, but styles still aren't being 
passed along to KMLs. For example, if I download KMLs of Land Use 1971 and Land 
Use 1999, I always get the Land Use 1999. Here is an example extent where the 
two land use layers differ, but I always see the 1999 version in Google Earth:

http://170.63.166.213/map_ol_mop/moris.php?lyrs=Land%20Use%201971%2021%20Classes
~massgis:GISDATA.LANDUSE_POLY|Land%20Use%201999%2021%20Classes~massgis:GISDATA.L
ANDUSE_POLY&bbox=-70.18310636617447,42.058374621945894,-70.17318219282149,42.065
591191036496&coordUnit=dms&measureUnit=m&base=googleSatellite¢er=-7812195.28601
06,5170268.7249225&zoom=10

Tested MORIS v. 0.62 with Chrome 14 on Windows 7.

Original comment by emily.hu...@state.ma.us on 18 Oct 2011 at 6:45

[GoogleCodeExporter]

I can confirm that mkzip is passing along the styles component for kml 
requests.  E.g.

http://wsgw.mass.gov/geoserver/wms?layers=massgis:GISDATA.LANDUSE_POLY&service=W
MS&version=1.1.0&request=GetMap&bbox=247698.08844815,822911.98053739,248614.0058
805,823776.33111695&srs=EPSG:26986&height=100&width=100&styles=GISDATA.LANDUSE_P
OLY::21_Classes_1971_Solid&format=application/vnd.google-earth.kml+xml

http://wsgw.mass.gov/geoserver/wms?layers=massgis:GISDATA.LANDUSE_POLY&service=W
MS&version=1.1.0&request=GetMap&bbox=247698.08844815,822911.98053739,248614.0058
805,823776.33111695&srs=EPSG:26986&height=100&width=100&styles=GISDATA.LANDUSE_P
OLY::21_Classes_1999_Solid&format=application/vnd.google-earth.kml+xml

Aleda, do you have the latest and greatest mkzip installed?  It should contain 
references to 'wmsStyle'.

Original comment by cpl...@gmail.com on 20 Oct 2011 at 1:44

[GoogleCodeExporter]

Original comment by Aleda.Fr...@state.ma.us on 20 Oct 2011 at 7:02

• Changed state: Verified

[GoogleCodeExporter]

Note: kml files were still getting named .tif.  A change to the mkzip file 
today fixed that.  It was committed.

Original comment by Aleda.Fr...@state.ma.us on 29 Nov 2011 at 5:45

[GoogleCodeExporter]

Emily noted this week that KML files are no longer being named their SDE name 
(back to folderset titles) AND they are not picking up the filter either (tried 
landuse).  Apparently our latest change to mkzip has broken these items for 
KML.  I've changed status from Verified back to Accepted so it will appear in 
Open Issues. 

Original comment by Aleda.Fr...@state.ma.us on 22 Jun 2012 at 8:21

• Changed state: Accepted

[GoogleCodeExporter]

r380 addresses this issue

Original comment by cpl...@gmail.com on 26 Oct 2012 at 6:27

[GoogleCodeExporter]

Original comment by cpl...@gmail.com on 26 Oct 2012 at 6:55

• Changed state: Fixed

[GoogleCodeExporter]

r390 passes along the wms style to kml exports

Original comment by cpl...@gmail.com on 31 Oct 2012 at 6:05

[GoogleCodeExporter]

Original comment by Aleda.Fr...@state.ma.us on 31 Oct 2012 at 6:24

• Changed state: Verified