Dynamic Map Rendering Size

Is there any way I can dynamically render a map’s width/height based off a shapefile?

The workflow I have working so far is:

  1. Import shapefile
  2. Add features
  3. Render shapefile as png
  4. Get byte array from png and render on Google Maps as an overlay

The issue I’m running into is not knowing what size to initialize the map to begin with:
using (var map = new Aspose.Gis.Rendering.Map(**600**, **900**))

All the examples I’ve seen have used hard-coded values, am I missing how to do this?

Hello, @kmochrie

Thank you for your interest in the Aspose.GIS product.

Dynamic map rendering size is possible if you can specify the cell sizes.

The size of a map in pixels and the cell size per pixel are interdependent, they can always be recounted among themselves. One of them is always required to build a map. We will consider the option to support the second scenario too. We have created a ticket GISNET-555 and will update you here as soon as additional information is available regarding this.

To successfully draw the overlap, You need to match the spatial reference, extent area, and the cell size (degrees per pixel) between google and your generated maps.

For Google maps, the spatial reference is usually a Web Mercator. Maybe you always work in a known area extent then you need to explicitly specify this extent. Our API allows you to specify an extent and a spatial reference for a map instance.

It is possible to calculate the width and height of the map if we get known the cell sizes for the map over which you are drawing. What is the provider your google map? If your use XYZ-tiles google servers, each z-level has a pre-defined cell size. Please share what maps are used and we will try to help you more.

Best regards.

Hi there,

Thanks for your quick response. We’re using Google Map’s JavaScript API to display the map view along with the image overlays. It appears Google Maps uses 256x256 pixel tiles…

Hello, @kmochrie

Indeed, Google Maps JavaScript API works internally with XYZ-tiles.

Consider calculating a map width as multiplying 256 by a tiles count by horizontally. Also, you need to determine the loaded area extent but I don’t know how to do it in Google API.

We are currently implementing access to tiled services like Openstreetmaps, Google Hybrid, Bing, OpenCycleMap, etc. You can see the details in this discussion.

Thanks.

Thanks. We just got it (somewhat) working using XYZ-tiles.

On each map pan or zoom, we call our service and

  1. instantiate a 256x256 Map
  2. load in the shapefile
  3. add the extent (found this helpful: Overlaying an Image Map Type  |  Maps JavaScript API  |  Google for Developers)
  4. render and return the png

Unfortunately we call this service every time the map is panned or zoomed, so the map loads very slowly. We’re loading the shapefile and rendering the png with each call, so I can only assume that has something to do with it.

Hello, @kmochrie

Consider the following code to improve performance.

  • open the layer only once

  • keep the vector layer open to reuse it in the next map rendering

  • specify the spatial reference of the extent, similar to our map.

      // open the layer only once.
      var file = GetShapefilePath(@"countries.shp");
      var layer = VectorLayer.Open(file, Drivers.Shapefile);
    
      for (int i = 0; i < 10; i++)
      {
          using (var map = new Map(255, 255))
          {
              // please use a spatial reference of extent the same as map to increase a performance.
              map.SpatialReferenceSystem = SpatialReferenceSystem.WebMercator;
              map.Extent = new Extent(-20037508, -19971868, 20037508, 19971868)
                  {SpatialReferenceSystem = SpatialReferenceSystem.WebMercator};
    
              // keep the vector layer open to reuse it in next map rendering. (specify 'keepOpen' as 'true')
              map.Add(layer, true);
              map.Render(@"countries.png", Renderers.Png);
          }
      }
    

In the example, I used a very large area (the whole world), so there will be an attempt to draw all the elements. For top-level zooms of the earth, it is better to create a specific shape file that will contain less details.

Best regards.