Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support imagery tiles created by MapCruncher #1378

Closed
kring opened this issue Jan 13, 2014 · 8 comments
Closed

Support imagery tiles created by MapCruncher #1378

kring opened this issue Jan 13, 2014 · 8 comments

Comments

@kring
Copy link
Member

kring commented Jan 13, 2014

MapCruncher creates tiles according to the Bing Maps tiling and naming scheme, but our BingMapsImageryProvider won't work well with it out of the box because it makes some assumptions that are only good for Microsoft's servers. It should be easy to make some changes to it so that it will work with MapCruncher-generated tilesets.

See this thread:
https://groups.google.com/d/topic/cesium-dev/flvoYwUD6aY/discussion

And MapCruncher is here:
http://research.microsoft.com/en-us/um/redmond/projects/mapcruncher/

@adi2412
Copy link
Contributor

adi2412 commented Mar 8, 2015

The main differences would exist in the URL format, the credits/image logo. The quadkey function should remain the same. I just went through the BingMapsImageryProvider file right now and I'm guessing that MapCruncher would need a similar object. Would the MapCruncher images be on the same server as the application or should there be a configuration to provide the REST API to fetch the MapCruncher tiles?

@kring
Copy link
Member Author

kring commented Mar 8, 2015

That sounds right to me. Yes, you'll want to create a separate ImageryProvider. It may then be trivial to implement the BingMapsImageryProvider in terms of your new one. You should not assume that the MapCruncher tiles are on the same server, but instead allow the URL to be specified.

@adi2412
Copy link
Contributor

adi2412 commented Mar 9, 2015

So I dug deeper to implement the MapCruncherImageryProvider and I've got some questions. BingMaps provides metadata(like tile width and height, maximum/minimum zoom, attributions) as part of its REST API. In the case of MapCruncher, a MapCruncherMetadata.xml(called MapLayers.crunched.xml in previous versions) file is generated containing this data. Should I assume that this file would exist in the same directory as the URL that would be specified by the user or does there need to be another configuration option to provide the metadata XML file. We could also just make the user enter these metadata values when using MapCruncher(if they aren't provided, give an error?).

Also, I wasn't able to find any template metadata.xml file. Does anybody have such a file or any idea of the structure of this file?

@kring
Copy link
Member Author

kring commented Mar 15, 2015

Hi @adi2412, I suggest you actually generate a MapCruncher tileset and use that as a reference. If MapCruncher creates the XML file in the same directory as the tiles, it's reasonable to look for it there. Alternatively, if the XML specifies the location of the tiles, you could have the user specify the XML file only and then the ImageryProvider could infer the tile location from the XML file.

@adi2412
Copy link
Contributor

adi2412 commented Mar 17, 2015

@kring Sure, I'll do that. There isn't a version for OSX which is why I was wondering if someone else would be having the XML file. I'll get a Windows machine to get this done though.

@pjcozzi
Copy link
Contributor

pjcozzi commented Aug 18, 2015

Is this still an issue given the new UrlTemplateImageryProvider?

@kring
Copy link
Member Author

kring commented Aug 23, 2015

Yes, this is still an issue, because UrlTemplateImageryProvider doesn't (yet) support Bing Maps style quadkey tile numbering.

@ggetz
Copy link
Contributor

ggetz commented Apr 13, 2023

This is unlikely to become a priority anytime soon. We'd still happily accept a PR addressing this issue. But tracking this isn't particularly useful because of its low priority, so I will close it. Thanks!

@ggetz ggetz closed this as completed Apr 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants