I can definitely confirm that rendering large map images via the API is
definitely memory intensive on the Mapguide site. Then when you get the
image out into .NET, you might even go into deeper problems with the way the
Large Object Heap collection works and so on. You can end up with pretty
massi
Did you update your binaries for Mapguide when deploying against 3.1.2? AIMS
2017's dlls are for Mapguide 3.1.1.4601, which isn't the same version.
Sometimes I've seen some issues when using the wrong version of the Mapguide
API dlls.
So make sure the content of your BIN folder has the dlls from 3
Might be worth looking into making sure you actually call Dispose on the
MgService you create. Also depending on what else you're doing, I'm guessing
you might have some MgByteReader and the likes that might not get closed and
disposed.
Mapguide also isn't "hung" when the pink map shows up, typica
I understand Mapguide might be useful for some low-end deployment that still
run on 32-bit hardware, but is that common enough to warrant making it a
much harder time on the already hard working devs of Mapguide?
I wonder the feasability of having a kind of hardware/os survey of folks
implementing
Hi,
I'm no Java expert, but I feel it could be a similar issue that you may face
with .NET and Large Heap Objects. With the size of the byte array you are
creating, 1024x1024, you might be overruning the size of the level 1
generation for the Garbage Collector and end up putting your data in a lat
This actually doesn't work properly due to the fact that the source
projection requires specific grid shifts for the transformation that aren't
provided by the Mentor coordinate system library.
There is an example of how to do it inside of Autodesk Civil 3D here:
https://blogs.rand.com/civil/2013/
A little bit ago, I remember OpenStreetMap started automatically redirecting
from http to https. Like if you navigate to
http://b.tile.openstreetmap.org/19/262144/262143.png you will notice you get
sent off to https automatically. I know this caused issues with Safari and
actually returned "pink im
This also occurs with OpenLayers v2 out of the box. It's a Chrome specific
thing that appears mostly common with mouse-wheel events and it's tied to
them improving touch functionalities. There doesn't seem to be a clean way
of working around the issue at first glance.
It doesn't halt script execti
Hi,
I was wondering if there are any logging tools I might be missing
specifically for when the MapAgent (in IIS) starts misbehaving. We call it
the dreaded pink map of death. Basically it stops returning images and
returns http status of 559 out of the blue. Only a restart of the
application pool
Hi,
If you use Maestro, which I am assuming you do, in the Tools menu you have a
"Server Status" tool which does show an Active Connections property. The
totals are, as you said, since the last server restart. So that can still
give you some live information about what is going on.
In your specif
Hi,
The issue is specifically for the new MgMap() line. The constructor for
MgMap was changed and the previous one was deprecated. You need to pass the
MgSiteConnection object when calling up the new MgMap().
So essentially you need new MgMap($siteConnection);
Hope this helps.
--
Sent from: h
Hi Jose,
The one thing I can think of is if the point layer stores data in geography
columns versus geometry. That is one of the reason I have had issues with
Mapguide on SQL Server.
Basically the directionality of the selection matters and it has to be
counter-clockwise. When the selection is dr
Hi Gorgon,
I believe FDO in general has some quirks with floating point precision. This
might be related to an issue I reported here:
https://trac.osgeo.org/fdo/ticket/929
I remember having similar issues back in my C++ days. Going from a floating
type to a string type would have quirky decimal v
While OGR is a neat provider, we did experience certain issues with it that
makes me feel that for some data sources it might not be the best solution.
We would basically get unreliable results when doing queries against it,
which isn't really good when users are trying to run queries on their data
Looks like you got it working better, but I will confirm that we do point to
\OSGeo\MapGuide\Server\Fdo\gdalplugins for the GDAL_DRIVER_PATH.
I do recall some weirdness happening when the alpha band was used in the
past. I'm going from memory, but I could be wrong. An ECW had 4 color bands,
so ARG
I'm kind of concerned about this. Not because it doesn't work in 3.1.0, but
because in all of our deployments thus far we have had no issues getting ECW
to work on Mapguide 3.1.0.
Would this be a Linux only issue or something else? I looked at what we
install and it's the content of the gdal-1.10-
Hi Jackie,
Thanks for posting that link and giving extra details about what the work
would entail. I couldn't find any information about how to go about
proposing a candidature for the PSC.
It's something that I would be interested in, considering Mapguide has been
part of my professional life s
I do believe you are leaking 1 MgByteReader per call.
Here is the definition of the function call:
public virtual *MgByteReader* CreateRuntimeMap(MgResourceIdentifier
mapDefinition, string sessionId, int requestedFeatures, int
iconsPerScaleRange);
It returns a MgByteReader. I strongly recommend
One thing to keep in mind is if you are batching all those calls to the
mapagent, you might be hitting the cap for simultaneously opened http
requests to the same server. It's a little bit different from browser to
browser, but typically only 4 to 8 http requests can be opened
simultaneously to the
Hi,
So I'm not sure if this issue is also present on Mapguide 2.2, as I'm
deploying an application using Mapguide 2011 Update 1. Still, I'm stupid
amounts of baffled by this issue. Nothing works right using the SDF
provider. Any queries without a geometry field made with SelectFeatures will
not r
This is a bit like comparing apples and oranges. The two are very different
kind of technologies. Google Maps basically renders maps using pre-generated
tiles. It has some good API for overlaying KML data, but that data will be
rendered client-side by the user's browser so any excessive amounts of
The Firefox issue is fairly straightforward to fix, except for my lack of
understanding of the actual cause of the issue.
In ApplicationDefinition.js, the method getAppDef(xhr) needs to be changed
to be like this:
getAppDef: function(xhr){
if (xhr && typeof(xhr) == "object" && xhr.resp
I was not able to extensively test this, but it seems as if when
MgSelection::AddFeatures is called, whatever FeatureSource was used for the
MgFeatureReader passed to the function will be locked and un-editable from
the various APIs, or from the Studio. This occurs using Mapguide 2.1 Beta 1,
using
23 matches
Mail list logo