PicturemarkerSymbol setWidth, setHeight Limitation

613
2
07-07-2021 07:44 AM
JensRohlfsen
New Contributor II

We want be able to show weather-, better stormcell-, regions of varying sizes at different positions on the world map.
For that purpose we have got a set of six predefined png-graphics, each one refering to dedicated dimensions in width and height.
Attached you see an example stormcell, which shall refer to a size of 100x100 NM (Nautical miles) applying its default dimensions in terms of symbol pixel size.

The idea for a simple kind of implementation achieving such behaviour is to use a PicturemarkerSymbol and "stretch" the graphic in terms of width and height when zooming into the map.

The general code idea is given here:

Esri::ArcGISRuntime::PictureMarkerSymbol* localWeatherSymbol = nullptr;
Esri::ArcGISRuntime::Graphic* localWeatherGraphic = nullptr;
double weatherLongitude_deg = 27.5;
double weatherLatitude_deg = 9.0;

//The following graphic shall represent an area of 100Nm times 100Nm
QString symbolPath = QString::fromStdString( rme::zero::pathname("resources/images/Map_Cloud_1_Table_Image.png") );//100x100NM
localWeatherSymbol = new Esri::ArcGISRuntime::PictureMarkerSymbol(QUrl(symbolPath));
localWeatherGraphic->setSymbol(localWeatherSymbol);
//set the position
localWeatherGraphic->setGeometry(Esri::ArcGISRuntime::Point( weatherLongitude_deg, weatherLatitude_deg, Esri::ArcGISRuntime::SpatialReference::wgs84()));

//Connect scale-change events to obtain actual scaling factor. Necessary as scaling can be a result of mouse-wheel actions.
//mapView contain the MapGraphicsView
connect(mapView, &MapGraphicsView::mapScaleChanged, this, &MapWeatherObject::updateLocalWeatherGraphics);

//UpdateLocalWeatherGraphics is called in case of map-scale change events
void MapWeatherObject::updateLocalWeatherGraphics()
{
//Adapt width and height according to zoom-level
double scaledwidthheight = 1500000000.0/mapView->mapScale();
localWeatherSymbol->setHeight(scaledwidthheight);
localWeatherSymbol->setWidth(scaledwidthheight);
}

What now can be observed is that while zooming-in applying a small zoom-level (i.e. large mapScale) everything seems to be quite good and acceptable. I.e. the graphic size linearily increases while zooming in.
At a certain mapScale-level, and I figured out it must be between the steps 1000000 and 500000 for the value of mapScale, the graphic size is not increased any more, although the parameter "scaledwidthheight" still increases!
I also tried it with different png-graphics with other default pixel sizes, but the result was exactly the same.

Is this a limitation of the PicturemarkerSymbol or a bug?
Do you have any recommendation or workaround?

Due to current system-wide use of Qt 5.9.7 we use arcgis runtime version 100.4.0.
We have 2D map, i.e. no 3d-scenes.

Thaks in advance.

0 Kudos
2 Replies
LucasDanzinger
Esri Frequent Contributor

If I understand correctly, you have weather radar images that correspond to a specific geographic area, and you want to display that on a map. Is that correct?

 

It sounds to me like displaying this data as a raster would be the ideal workflow, as PictureMarkerSymbol is really meant to display a Point geometry. I am concerned that with your scaling workflow, that it will be quite imprecise, especially depending on the spatial reference. With all of that said, I'm not sure if what you are describing is a bug or not - would need a small reproducer app to test. Does it seem like it hits a max size where you can't increase the size any further?

 

To display as a Raster layer, you can add your image file as a Raster/RasterLayer to the map. https://github.com/Esri/arcgis-runtime-samples-qt/tree/main/ArcGISRuntimeSDKQt_CppSamples/Layers/Ras... 

 

However, do you have a world file or some other projection file  to define where on Earth the image corresponds to? This will be needed to display the raster in the correct location.  https://pro.arcgis.com/en/pro-app/latest/help/data/imagery/world-files-for-raster-datasets.htm 

 

Alternatively, you could use KmlGroundOverlay to add an image and define the extent for where the image will display, but this requires 100.6 or newer (which will bring in a Qt 5.12 dependency). In addition, ImageOverlay could eventually be a good solution for you, but it is only available in 3D at the moment. We hope to add 2D support soon.

 

My recommendation for the time being would be to try and create a world file for your raster dataset and display the data as a raster on the map. This will be the most accurate, bug-free, and performant option for displaying images on a map. 

 

Here are some links to the KML and ImageOverlay samples to see what I am talking about 

 

https://github.com/Esri/arcgis-runtime-samples-qt/tree/main/ArcGISRuntimeSDKQt_CppSamples/EditData/E...

 

https://github.com/Esri/arcgis-runtime-samples-qt/tree/main/ArcGISRuntimeSDKQt_CppSamples/Scenes/Ani...

0 Kudos
JensRohlfsen
New Contributor II

Thanks for your reply Lucas! Yes, the use case basically is to depict a kind of predefined radar-image which we have available as png-graphic. This image shall move in position (lat/lon) over time -as real weather-areas do- and should be variable in terms of size, i.e. a kind of diameter refering to circular shapes, or height/width refering to more quadratic shapes.

As the original png-graphics shall per definition refer to a 100NM X 100NM area, the idea was to "stretch" this graphic to represent other dimensions. E.g. a "stretch" by factor 2 leads to the dimension 200NM X 200NM and so on. In addition the zoom-factor must be taken into account. That is what I tried to explain above. I absolutely understand your concern about the scaling workflow. But we think for our purposes it is accurate enough.

What we simply observe when zooming-in to these high scale-levels is, that the graphics isn't stretched any more.

I think we will in fact have a look on the KML-solution you proposed. Adding raster layers should not work for us, as the images shall dynamically move in position over time, if I understand this correctly.

0 Kudos