Closed GoogleCodeExporter closed 9 years ago
Original comment by emily.hu...@state.ma.us
on 5 Jul 2011 at 8:33
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Issue 35 has been merged into this issue.
Original comment by emily.hu...@state.ma.us
on 26 Sep 2011 at 6:09
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
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
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
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
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
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
Original comment by Aleda.Fr...@state.ma.us
on 20 Oct 2011 at 7:02
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
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
r380 addresses this issue
Original comment by cpl...@gmail.com
on 26 Oct 2012 at 6:27
Original comment by cpl...@gmail.com
on 26 Oct 2012 at 6:55
r390 passes along the wms style to kml exports
Original comment by cpl...@gmail.com
on 31 Oct 2012 at 6:05
Original comment by Aleda.Fr...@state.ma.us
on 31 Oct 2012 at 6:24
Original issue reported on code.google.com by
emily.hu...@state.ma.us
on 5 Jul 2011 at 8:30