Subscribe to this thread
Home - Cutting Edge / All posts - Manifold 9.0.180.1
adamw


10,447 post(s)
#08-May-23 16:33

9.0.180.1

manifold-9.0.180.1.zip

SHA256: 43ed9ff9d0b558e26ad4108134f9c60ed29f3a4edf8b5146c87461f2ae5928d9

manifold-viewer-9.0.180.1.zip

SHA256: 7aa9e372b2a7f2ff247c1bf483e51242baf368a88e9e55e248c313bd9c7def8a

sql4arc-9.0.180.1.zip

SHA256: 8b3fc46555cbe0651531264c4f3133dc4092999658d3c732be28694a1c019f4a

adamw


10,447 post(s)
#08-May-23 16:34

Changes

Launching Manifold in the context of an external application via ODBC, COM or .NET no longer places any restrictions onto the COM threading model of the calling thread. (Previously, the calling thread must have been using COM STA, otherwise attempting to launch Manifold would fail.)

MANIFOLDSRV allows specifying the server type using the -type:xxx command line option. Specifying -type:http runs the HTTP server, specifying -type:tcp runs the TCP server (the default).

The Universal edition is limited to a single server instance regardless of its type (you can only run a single TCP server or a single HTTP server, but not both simultaneously).

The HTTP server serves a single component (drawing / image / labels / map). The name of the served component is specified using the -component:xxx option, the default is 'Main'.

The HTTP server implements HTTP/1.1. The supported methods are: GET / HEAD. All text is returned as UTF-8. All images are returned as PNG.

The HTTP server accepts multiple HTTP requests queued to the same connection without waiting until the first requests are processed.

The HTTP server, similarly to the TCP server, can run as a service.

The HTTP server does not use the -workers:xxx option. Threads used by the HTTP server are organized differently from threads used by the TCP server, the number of threads for the HTTP server is managed automatically.

The HTTP server does not use the -user:xxx and -password:xxx options. (In the future, we might support them for HTTP authentication, but this is not a priority, it is generally better to use client-side authentication.)

The HTTP server defaults to port 80 (unlike the TCP server that defaults to port 9099).

MANIFOLDSRV shows the server type in the window caption when running in a console window.

Map images rendered by the HTTP server have the 'manifold.net' watermark in the right bottom corner.

The web page served by the HTTP server is organized so that the map UI is put into a Javascript control and the page itself merely creates and initializes that control. This allows putting the map served by the HTTP server onto an existing web site with minimal changes. See the post for web developers below for details.

The web page served by the HTTP server shows the name of the served component in the page title and above the map.

The map UI used by the HTTP server allows panning the map using the cursor. Pressing Escape while panning cancels the operation.

The map UI used by the HTTP server allows zooming the map using the wheel. Multiple zooms from the wheel are combined together, the map is updated after the wheel is not scrolled for 1 second.

The map UI used by the HTTP server shows buttons in the left top corner of the map: zoom in, zoom out, zoom to fit. The extent used by zoom to fit ignores layers for web images such as Google or Bing unless all other layers in the map are empty.

End of list.

(Next for the HTTP server: many extensions to the map UI with new REST endpoints, support for WMS, maybe support for HTTPS. Other than that, with the core of the HTTP server mostly finished, we are free to move back to tasks unrelated to the web and tasks that benefit the experience on both the desktop and the web.)

oeaulong

521 post(s)
#08-May-23 21:32

my mind has been spinning all day with the opening of web presentation options.

well done. the silence before the drop was thick.

danb

2,064 post(s)
#08-May-23 22:10

Wonderful to see. This is a great addition to the growing Armory which I can't wait to get stuck into.


Landsystems Ltd ... Know your land | www.landsystems.co.nz

adamw


10,447 post(s)
#08-May-23 16:36

For web developers:

How to put the map served by the HTTP server onto an existing site:

The HTML code of the web page looks like this:

<script src="webscript.js"></script>

<script>

 

  window.onload = function () {

    let config = {

      bounds: { xmin: xxx, ymin: xxx, xmax: xxx, ymax: xxx, },

      cx: 800,

      cy: 800,

      urlbase: "/",

    };

    manifold.createMap(document.querySelector("#map"), config);

  };

 

</script>

 

...

 

<div id="map"></div>

The above can be put into an existing web site served by a different web server like IIS or Apache. The URL for the script and the urlbase config parameter have to be adjusted to point to an appropriate instance of the Manifold HTTP server.

After that, when the web page loads, the script will define the manifold object and the call to manifold.createMap will create all necessary HTML elements for the map UI in the specified div, style them and wire them to events. The content of the div will then display the map served by the Manifold HTTP server and allow operating it.

Future extensions to the map UI will only affect the config section in the inserted code.

REST endpoints:

/map?... - the map image, accepts the following parameters:

  • bounds=xmin,ymin,xmax,ymax - the bounding box to render, the default is full view,
  • size=cx,cy - the dimensions of the image to render, the default is 800x800, neither cx nor cy may exceed 4096.

End of list.

rvrsabbs22 post(s)
#18-Dec-23 00:27

[deleted - please start a new thread]

Dimitri


7,413 post(s)
#08-May-23 18:22

I've been playing with this and it's really easy. Basically, build 180.1 adds an internet map server, a web server, to Manifold Server. You need either Universal Edition or Server Edition to use this, just as with regular Manifold Server. You don't need IIS or some other web server, like Apache, installed on the machine.

You can create a web page served by any machine on which Universal or Server editions are installed just as easy as running Server. Suppose for example you want to serve a component called "Map" that's in a project saved in a .map project file at C:\Projects\Mexico.map. Say the server machine's IP address is 192.168.2.12.

1. Visit the User manual topic on Manifold Server and read it.

2. If you're running Universal edition on the server machine or you want to launch server from a command line, launch a command window as Administrator and then navigate to where your manifold.exe and manifoldsrv.ex files are and enter the following command line all on one line:

manifoldsrv -addr:192.168.2.12 -port:80 -type:http -component:Map "C:\mfd\projects\meteorites.map"

That launches the http server running on IP address 192.168.2.12 listening on port 80, the default for http connections.

Launch a browser on the same machine and visit http://192.168.2.12 and you'll see the served web page created by the above.

If you want to browse that machine from some other machine, you'll need to launch Windows Defender Firewall and if you haven't already added the manifoldsrv.exe executable that you're using to the exceptions list, do that so it can communicate on private and public networks.

If you have a full Server license, then you can launch Server (as an Administrator, of course) interactively like any Manifold session, and using the Tools - Manage Services tool you can add a service like this:

Start that and you have a web server running on the machine. Browse it using any browser to visit http://192.168.2.12 and you'll see the display, like this:

The point of all the above is that if you have a Universal or Server license, you now have a GIS web server. No need for IIS, Apache or anything else to provide Internet Information Services or web serving. That's all built into Manifold now. You also don't have to write any web pages, either.

You can, of course, write web pages in the usual way on your web server machine (with server also installed, of course) and launch the http server from within a web page, as adamw's post describes. But you don't have to do that. There will be more options added over time to the very simple default page. But even as simple as it is right now it can be used to browse any component in a project that's being served.

If you have a Server license, you can, of course, serve multiple projects at the same time. Just use a different port for each (80, 81, etc.).

Performance is great. The only slow down is if you use Bing or Google or some other image server in your served map, however long it takes Bing or Google to serve tiles into that image is going to be a delay. Be careful using such image servers in live apps because if you have a zillion people browsing your site you're going to be sending huge numbers of requests to Bing or Google and that probably won't fit into whatever they allow you for free usage (or your API key's service limits that you've bought).

It's also really easy to change what's being served. When I did my first example, using the Mexico map, I deleted the Bing layer from the Map. I was using a Server license, with Server running as a service. OK, so when I decided to change the map to add a Bing background layer, on the server machine I launched Manifold, in Tools - Manage Services I stopped the running service, and then I loaded the Mexico.map project. In the project I added the Bing background layer to the map, saved the project, and closed it. I then launched Tools - Manage Services again and started the Server service.

Instantly, on any other machine that I had a browser connected to http://192.168.2.12, if I did a refresh it showed the new map, as I changed it. Can't get any easier than that. :-)

Some people may want to use https. If you do that use a web page that's https and put the manifold server http part into the web page like adamw's post says.

Enjoy!

Attachments:
http_server01.png
http_server02.png

Mike Pelletier

2,122 post(s)
#08-May-23 19:54

Congratulations on getting over this big hurdle. It indeed looks great! Perhaps its premature, but it would be interesting to get your take on the pros (looks like many) and cons vs Arc Online.

As features are added to the map UI, I'd encourage Mfd to consider better labeling as an extremely important element. Poorly placed labels stick out like a sore thumb, which isn't good when the Manifold.net watermark is just below. Nevertheless, great to see that Mfd pushed ahead on web server and put together a simple to use and powerful infrastructure.

Dimitri


7,413 post(s)
#10-May-23 13:17

the pros (looks like many) and cons vs Arc Online.

Well, it's early days so hard to say how that will play out.Serving to the web what's accomplished with a desktop GIS is a pretty big tent so there is a lot of room for new things, like Server, that provide conveniences people want.

There are very many issues involved in ArcGIS Online compared to Server, so this isn't a short post. Here goes...

My guess is that there will be significant overlap and co-existence between the AGOL (ArcGIS Online) and Server communities. There's nothing wrong with having more options, and the low cost of Server gives it appeal even just as an accessory within a continued focus on Esri. For example, it could be the easiest, least expensive way to publish content from an Esri file geodatabase or Enterprise geodatabase to the web.

AGOL is a great offering from Esri. It makes it easy for the Arc community to share through the web what they've created on their desktop and it's well integrated with Esri's suite of capabilities for collaborative work. Those are big pluses. For many people, it's also a plus that AGOL runs in Esri's cloud: they don't have to use one of their own machines as a server.

Despite all the many good things about AGOL there are a few minuses:

Default loss of property rights on AGOL - Esri's "Permission to reproduce" term in AGOL terms of use says "By sharing content publicly ... you expressly grant Esri and end users of ArcGIS Online permission to use, reproduce, prepare derivative works of, and distribute content". There's a squishy phrase about "subject to any use constraints you provide," but the default is that you lose your intellectual property rights. Ouch.

Noncommercial only - Esri's terms also say "Groups of a commercial nature designed to promote a service or product are not allowed." Sounds like if you're a contractor wanting to showcase your portfolio to sell services to more clients, AGOL is not for you. Same with a website to show people how to get to your stores, car dealership, etc. Even if all you want from AGOL is to publish a static map (screen shot or PDF in a report or brochure) you need to get permission from Esri for "commercial monetization" or "direct resale". There are lots of other strings attached. For example, you can't resell, rent, lease, etc., AGOL sites.

Depends on a third party monopoly - That's also a minus for many people, that AGOL is software as a service and it exists only within Esri's cloud at Esri's control based on Esri's sole and exclusive judgement. Esri is a total monopolist on AGOL so there are no alternatives if you want lower prices or better terms on AGOL.

You rent it, and you don't own it. If you don't keep up your subscription at whatever Esri's latest pricing requires, it's gone. If Esri's cloud goes offline, your sites are gone. If Esri decides they don't like your politics or your content, your sites are gone. If there are any disputes with Esri or mistakes on Esri's part, it can take a while to find out what's the problem and to get your sites back online. If your underlying data is secret (shouldn't be, if it's on AGOL), you have to trust Esri isn't inspecting or leaking your data.

Cost - AGOL can be very costly. It's far more expensive in most cases compared to running Server on a spare machine.

Performance - AGOL can have poor performance with bigger data, since it's still running Esri's stack. Rasters are slow, with no GPU or CPU parallelism for hundreds of query functions for rasters and such.

Interoperability - AGOL has the usual Esri limitations on data sources. It doesn't have the zillions of data sources Manifold has, like direct connections to PostgreSQL/PostGIS as illustrated in Art's blog post, as opposed to connections to Esri's proprietary "SDE" architectures. There's no ability to create layers using SQL from multiple enterprise DBMS packages at the same time, like Oracle and SQL Server and Postgres, etc.

Legal risks - Esri is a highly US-centric organization, which is business as usual for US organizations but may be a bad thing for users in the rest of the world, because of a variety of issues ranging from compliance with US, EU or local regulations to litigation and tax risks.

People usually don't think much about such factors in an era of blind trust in third party providers, but that's just one example of how the conveniences of outsourcing only work out beautifully until they don't. As people more and more place their fate in the hands of third parties you get many more examples of how that can go frighteningly wrong, like people who can't use any part of their many business documents in some online office ecosystem because for some reason their "too big to fail" tech vendor has decided that their account has been compromised. Anybody who's been locked out of their giant tech provider account can talk about the labyrinthine, Kafkaesque difficulty of regaining access.

Compared to the above, Server has significant advantages:

You own your work product - No problem using Server for commercial purposes, and your work product is yours. There are a few exotic exclusions under the general Manifold license, like you can't use Server to control a weapons system or run a nuclear power plant, but in general if it's legal in your jurisdiction it's up to you what you do with it. Want to create a website where you charge people a fee ("commercial monetization") to create a custom map? No problem. Want to use Server to create web sites for third parties that you operate on your server? No problem. You could be a contractor who uses a single Server license on your machine to operate public facing websites for three or four different counties, each with their own domain. Want to use Server as one of the elements of a paid web-based application, like a real estate sales or search application? That's OK, too. Can't do any of that with AGOL.

With Server, what you put on your site is your business and doesn't have to be approved by anybody else.

No need for third parties, no service monopolies - With Server, there is no need for any third parties to be involved. It's your server and you can do whatever the heck you want. You can involve a third party if you want, for example, by outsourcing your computer infrastructure to a dedicated server maintained by some other company, but if you choose to do that you have many alternatives and options for vendors that help keep prices and terms and conditions reasonable.

Far lower cost - After your initial procurement of Server, a max of $395, you have a fully paid license you can use for years for an unlimited number of web sites on the server machine for zero additional cost. It doesn't matter how many visitors or how much data is involved.

Most Internet providers in most countries can arrange a static IP address even for home users that costs nearly nothing, like an extra $5 per month. Even a ten year old spare machine running Server likely can host tens of thousands of users for most web sites powered by Server so the cost of the machine often is zero if you use some old machine you have lying around. You could even use the same machine that's your desktop if it's just a personal or small organizational site. That's way less expensive than running AGOL.

An organization can easily rent dedicated servers from providers if it wants to outsource hardware maintenance, backups, and such and it will still be much lower cost than AGOL.

Very easy to use - AGOL is pretty easy to use, but Server is even simpler.

Better performance, interoperability, etc - Manifold is profoundly faster than Arc, it's way more interoperable, and so is Server.

Lower legal risk - If you want to be insulated from insane litigation risk or if you're a civil liberties, humanitarian or environmental activist living under an authoritative regime, get a server provider or a proxy in a country that has "loser pays" provisions and airtight privacy regulations.

Server downsides compared to AGOL:

AGOL has more features today. With Server you get (at present) a simple display that's easy to create. With a few additions that are already in progress, as Art mentions in his post you get what 80% of users will need, and with a few additions more (also underway) you'll get what probably 95+% of people using AGOL do.

AGOL has a big, curated library of layers you can use - But almost all are available to Server users as well. Manifold can use such a huge range of data sources that you can pretty much use any free or paid web resource that's out there.

Manifold could add a few more things to get more overlap with AGOL users.

For example, there could be a "Publish to the web" button in every Manifold desktop license where you could have a remembered Server, or list of Servers, IP address with your credentials. Pushing the button would automatically package the project and upload it to that server and also create and start a Server service given what options you've checked off in the "Publish to the web" form.

Sooner or later Manifold will introduce map 2.0 upgrades to Manifold's internal database which will enable read/write operations. That would facilitate simultaneous, read/write collaborative operations. You can do that now using a DBMS like Postgres as a data store, but it would be easier for teams if there was no need for anything other than Manifold.

Manifold could also expand the repertoire of presentation capabilities to do things like story maps and reveal swipes. That all depends on what priorities the user community sets.

I think that for a long time AGOL will continue to be the choice of Esri-centric organizations, especially in the US, who are spending a lot of money per year on Esri services. Things like managing litigation risks are already a cost that's baked into the hundreds of thousands, or millions, they spend per year renting software as a service from Esri.

In contrast, Server has a lot of appeal to GIS users and organizations who just want the convenience of getting a high performance, web-facing GIS-enabled site up and running quickly and inexpensively. Server also allows commercial and other entrepreneurial uses that don't fit the AGOL model. That includes smaller organizations, individuals like private users, contractors, consultants, and individual users or sub-organizations within large organizations. Even within very Esri-centric organizations there are Manifold users who will find Server to be a convenient alternative to jumping through bureaucratic hoops to use their organization's AGOL accounts.

adamw


10,447 post(s)
#10-May-23 14:41

A very short note on the technical pros of our server compared to ArcGIS online for end users:

  • very easy to set up and operate,
  • very easy to integrate into an existing web site,
  • updating content is very easy, too (you stop the server, load the MAP file, edit it, save it, restart the server, done).

All of these 'easy' things will stay easy, too.

In the future, we are planning to also have:

  • tons of rich and useful tools that can be added to the UI and configured - and - adding and configuring each tool does not require any programming skills, you just edit the configuration data (JSON).

That's it for now.

BCowper


1,275 post(s)
#10-May-23 14:58

One disadvantage of ArcGIS Online's cloud hosted data for users is there is no backup up built in. Delete a point and it's gone forever. Bigger organizations can buy third party tools to do daily\weekly backups of ArcGIS cloud data, but it is risky not having immediate undo or backup capabilities in place. Large organizations will use their own servers for important data, but that comes with additional equipment and license costs. If you are using these maps for field data collection, losing data can be quite costly.

I would assume using Manifold 9 would give more options to backup your local Map file and associated data.

Dimitri


7,413 post(s)
#10-May-23 16:35

I would assume using Manifold 9 would give more options to backup your local Map file and associated data.

Yes, I think it would. If all your data is kept in a .map file that's easy to back up: stop the server session, copy the .map file and paste to a backup location, restart the server.

If you're talking about dynamic updates to a map layer that's being served, that's a read/write proposition where you want that layer in a read/write data source like a PostgreSQL/PostGIS DBMS. All your other layers, of course, could be in any other data source, including the .map file itself.

But once you have a layer that's getting dynamically updated, say, from the field or from multiple desktop users editing something like a town's parcel file, stored in a Postgres (or other DBMS) DBMS, well, then you have pretty much unlimited ability to back that up as you see fit, on the fly without even stopping the server session.

Also, if you're doing field work and exposing the updates in user-browsable web sites using Server, you could use KoBo Toolbox with the Kobo Server, like in the KoBo example. That would be an interesting example for Server.

BCowper


1,275 post(s)
#10-May-23 17:33

Thanks Dimitri. I'd seen your posts over on Reddit about Kobo, good to see alternatives to ESRI available.

Mike Pelletier

2,122 post(s)
#10-May-23 17:18

Thanks to you both for the helpful comparisons. It's clear that Manifold has the better infrastructure for us GIS folks for so many reasons. It's a fantastic development.

On the other hand, I think the "tons of rich and useful tools" is what often drives the show because its what the users see. No doubt in my mind they will come. I appreciate the spirit of Art's helpful 80% usage with 4 tools suggestion, but I just think that it will take more like a couple dozen UI tools to be practical. Realizing of course that its a dance for where to spend Mfd energies!

artlembo


3,400 post(s)
#10-May-23 17:41

yes, ArcOnline, and its integration with the entire Esri world is really nice. Esri has all kinds of really great goodies in the cloud, including routing services. Just super convenient to use.

Also, if you are familiar with Model Builder, you can build your own model, turn it into a Script Tool (with a really nice GUI), and then put it in the cloud for all the other users to access. Very good stuff, for sure.

It's interesting when you consider how long GeoServer has been in existence, and to this day, nobody has cobbled together an open source ArcOnline - it simply takes too many man years to pull that off.

It will be interesting to see where all this goes, especially if some standard templates are built (for things that replicate a search portal, standard IMS layouts, etc.).

artlembo


3,400 post(s)
#08-May-23 23:49

super easy to set up, and no webserver or map server necessary. And, I think we all "get it", that what is there now is just the first proof-of-concept.

What I am happy with is that I can take a 2GB .map file and easily publish it, and it displays in no time. Millions of object, just appear instantly.

I also took the Philadelphia data that I have here, and just made it a web map. So easy, it's almost scary. I also took the crowd source bathymetry work I'm doing which has tons of tunneling into other servers, and that just popped into existence. Again, just super simple.

I don't know how frequently the updates will be, but I think the next big things (even before WMS and WFS, etc.) is to move this out of "cute" to powerful is:

  1. allow the user to turn a layer on/off
  2. click on an object, and return the attributes
  3. create a bookmark, allowing users to zoom into a location
  4. add a measure toolbar

I even thought about allowing a right-click zoom to box, but honestly, most people can scroll with their mouse or keypad. If any minutes are going to get devoted to this, I'd like to see those 4, in order.

that creates a very navigable web map that handles 80% of what most people need. From there, allowing this to spit out endpoints for WMS, WMST, REST, WFS, etc. would be nice.

of course we all want the SQL that IMS 8 had in it, but I'm willing to wait on that in the short term.

Like I said, 80% of what most people need to use a web map for is tied into those 4 things, and the ease at which this gets loaded into a web map is stupid simple.

artlembo


3,400 post(s)
#09-May-23 01:50

also, very nice to see that scalebars, legends, and scale rendering all work on the web.

Sloots

678 post(s)
#09-May-23 08:11

allow the user to turn a layer on/off +1

click on an object, and return the attributes +1

I would like to add the possibility to filter objects somehow in an SQL-ish way. E.g. the user checks a checkbox and the server filters out all the large meteorites originating from Mars. (size > 500000 and origin = 'mars')

In other words a flexible tool to do filtering and trigger the filters by checkboxes, sliders, drowdowns etc.

I have done some test on my local machine and the speed is impressive. One annoying detail: the zoom function with the mousewheel works different than Manifold itself. It doesn't take into account where the mouse is positioned, always zooms in/out at the center of the screen.

Can't wait to see more...


http://www.mppng.nl/manifold/pointlabeler

adamw


10,447 post(s)
#09-May-23 13:16

Answering both you and Art.

Yes, obviously, we are planning to extend the map UI in many ways:

  • turn layers on and off - yes, plus perhaps a limited way to do that (eg, not being able to control everything, but rather, say, taking 5 layers and switching between which one of them should be shown with the rest hidden - basically choose whether you want to see restaurants or gas stations or whatever, but just one type at a time) if you care about the performance because this greatly helps caching (far fewer possible combinations of layers),
  • click on an object and show the attributes - yes, of course,
  • create a bookmark and zoom to it - yes, define locations in a MAP file, then tell which ones to use on the web,
  • add a measure toolbar - yes, a no-brainer.

For queries, we'd obviously like to support SELECTs. Ideally, we'd also have means to declare parameters so that those can be entered, ideally with more than just textboxes (checkboxes / sliders / dropdowns, exactly). This applies to the desktop, too. We are talking about different ways to display the results of a SELECT on the map. For web, we'd likely want those results to be on top of the map, this makes them more responsive. Eg, say, the query returns a hundred points, we'd show all of them as bluish circles on top of the map, then you'd be able to click one of them and we'd make it bigger and make it red and show its attributes - all without going to the server - if the selection is embedded in the map image, we cannot do that.

There are multiple other things we'd like to add, too. Some of them, similarly to being able to declare the parameters of a query as mentioned above, also apply to the desktop. For example, we are considering adding tooltips, these would work both on the web and on the desktop.

The best thing is, we can now be working on all these features independently of each other and in parallel with other features in other parts of the product. Because all the major heavy lifting has been done. :-)

oeaulong

521 post(s)
#09-May-23 14:41
  • click on an object and show the attributes - yes, of course,

click on an object and launch some Event(), Msg(), or Script() ??

or is this expected to be handled at the client layer only?

oeaulong

521 post(s)
#09-May-23 14:57

Just remembered I left the server up last night. After a cryptic social media post, 160 hits on the map service in 16 hours. It cooked through the night with my late nite friends bouncing a test map of interest. I am looking forward to this.

adamw


10,447 post(s)
#10-May-23 14:04

The Info tool will go to the server to fetch the data. Initially we will probably only fetch the data for a single object, but that might be extended to fetch the data for say, up to 10 objects that are close to the click location, with the UI going through these objects similarly to how the Info pane does that on the desktop right now. Going through the fetched objects will not have to hit the server again, obviously.

In general, the web UI will stay mostly single-page (ideally, we will have no full refreshes ever) and the UI logic will be split between the client and the server, meaning that both sides will do a significant part of the work.

oeaulong

521 post(s)
#10-May-23 21:55

Thx Adam. These clues help me to plan and plot. Looking forward to some dramatic steps forward now that the foundation is curing.

lionel

995 post(s)
#18-May-23 22:58

when read "extend the map UI" ...this make me think of the many gis php plugin for CMS like joomla or wordpress or drupal .....:

Web Maps for WordPress (Free Version) - GEO Jobe (geo-jobe.com)

Plugins categorized as gis | WordPress.org

WISroGIS mapping, by WIS.ro - Joomla Extension Directory

Geek OpenStreetMap, by JoomlaGeek - Joomla Extension Directory

Found 52 results containing the words: gis map ui | Drupal.org

Leaflet for UI and google/Yahoo/osm and virtual Earth map are common words use for describe thoses plug in !! some plug ins are compatible with WMS server.

geoclip ( https://www.geoclip.fr/?lang=en) is the best to see what kind of things/fonctionnalities can be implemented in the UI client side ! the UI implement a switch beetwen a table and gis map with some infography to better show datas and implement TJS - Table Joining Service ! Most of the time the gis data appear after use a form to select/show custom data in differents level of map ( commune, département, région) !! see Observatoire statistique des télécoms - Indicateurs : cartes, données et graphiques (geoclip.fr)

Arcgis use SDK for javascript or 3D SDK engine for unity with many type of events !!

DefaultUI | API Reference | ArcGIS Maps SDK for JavaScript 4.26 | ArcGIS Developers

javascript on web and C# in desktop are 2 differents worlds. I ll dream of C# code that can be write debug & run on http server by only use Manifod GUI !!

Manifold hosting choice was very poor .... self hosting was the best choice that manifold do to share data online !!

The UI ( gis form ?) that ll appear in manifold http server ll depend of the wish of end users express/send by mail !!

really like the work that manifold team do on version 9 even 8 was really really great !


Book about Science , cosmological model , Interstellar travels

Boyle surface fr ,en

Dimitri


7,413 post(s)
#11-May-23 07:47

A correction to my big post above, regarding:

If you have a Server license, you can, of course, serve multiple projects at the same time. Just use a different port for each (80, 81, etc.).

The example I gave of using ports "80, 81, etc." is bad advice. Port 80, of course, is OK as that's the default HTTP port, but using port 81 is a bad idea since it is often used by other software.

A better idea are the IANA "HTTP alternate" ports like 591, 8008, and 8080. Or, use some high port number that's unused. For example, ports 44300 to 44399 are unused, so you could use 44351, 44352, 44353, and so on.

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.