does Arcgis .net runtime include any classes to load data from WFS and display it as a layer? I have been reading documentation and cannot find any WFS support. FeatureLayer seems to work only with arcgis servers.
My current solution: Request Geoserver -> parse gml -> display it as GraphisLayer filled with SimpleMarkerSymbol. I dont think its optimal, is there any better way of doing this?
Thanks for info.
WFS is not supported by the Runtime at this point. It is however on the roadmap, but I don't have any specific timeframe for it at this point.
Your current solution should work for now, but you might want to consider using FeatureCollection instead of GraphicsLayer, since it is better at rendering large amount of features with less memory load.
WFS (read-only) will be supported in the upcoming 100.5 release of ArcGIS Runtime.
Related
I'm using arcgis to find the nearest distance from my lat/lon points to coastline. I use the near tool in arcgis. however, i realize that the "Geodesic option" is missing from the arcgis i'm using. i suspect this is a version problem, does anyone know?
many thanks!
The Method parameter (allowing you to choose between PLANAR and GEODESIC) was added in ArcGIS 10.2.1, so you're probably using an older version indeed.
See What's new in ArcGIS 10.2.1 for reference.
I'm trying to see if there is a way to use a dynamic map service layer as a source for the Search Widget provided in the ArcGis Javascript API. As far as I can see from the documentation, only feature layers are supported.
Is there some sort of work around? Potentially using Locators?
What are Leaflet and Mapbox, and what are the differences or usages of both? What are the main differences in their APIs?
The other answer is good but a bit outdated, since Mapbox has changed significantly in two years.
Leaflet is a JavaScript API for making maps interactive on the internet. It can integrate with Mapbox, but also plenty of other tile sources, like OpenStreetMap, and other data sources, like GeoJSON overlays.
Mapbox is a company that provides map services and technology - one of those services, Map tiles, can be used in Leaflet as base maps - same as you'd use Google Map tiles in the Google Maps API. Mapbox also develops a Leaflet plugin called Mapbox.js that makes it simple to integrate with their tiles while still using all of the great functionality in Leaflet. We also support Leaflet's development, since the maintainer works here.
You can use Mapbox.js without using Mapbox tiles, and use Leaflet with Mapbox tiles - they're entirely mix-and-matchable. Mapbox.js's additions, like TileJSON and UTFGrid support, make it easier to integrate with Mapbox maps, but don't change the existing behavior of Leaflet.
Update (2014-08-22):
My answer is slightly outdated. Please refer to #tmcw's answer for an up-to-date comparison between Leaflet and MapBox.
Original Answer (2012-09-05):
You're comparing apples and oranges.
Leaflet is "just" a map API. It doesn't provide data/maps itself. Mapbox is a service to design and publish maps, where the end-result is a bunch of generated map-tiles stored in the cloud (and some json files).
Thus, for example, you may consume Mapbox maps from Leaflet. Example
Anyway, Mapbox is developed by a company called DevelopmentSeed, and they have a map API which is indeed a Leaflet competitor, called Modest Maps, although much simpler and with less functionality.
So, to sum it up:
Leaflet -> map API , no data
MapBox -> design and publish maps
You can think of
Mapbox as the GitHub of the maps
OpenStreetMaps as git
Leaftlet as a git client
and mapbox.js as the 'GitHub for Mac'
Let me try to explain more:
OpenStreetMaps (OSM) is an open source project to create/display maps & geo-data; just like git allow to create commit trees for source control. They both are software that handle data.
Mapbox is a hosting company for OSM-based maps with some more power rather than just hosting; which is the same case of GitHub for git projects.
Leaftlet is a library to enable users to display/use OSM based maps on their browsers using OSM hosting service; just like any git client is doing with git hosting services.
mapbox.js is an enhanced library to display/use maps hosted at mapbox.com, which is already based on OSM; just like the "GitHub for Mac" client is made by GitHub to provide an interface to the projects hosted on their servers.
Hopefully this clarifies your doubts.
It is an old post, here is my update.
Mapbox now is using leaflet as their official JavaScript API (I don't know what's the internal working, but... I can't visit Modest Maps at all, and Mapbox doesn't mention anything about Modest Map on their current website).
Leaflet is better I suppose. It gives you flexibility to choose your map source and edit the features as you'd like to! It's just a bit time-consuming to learn though! And the top reason: it's free!
I am developing a web-based simulation where I want the front-end to be "animated" in real-time--it will be a mapping application, and I want to have little icons (representing the components of my simulation) moving all over the map as the simulation runs. I am developing the back-end in Rails, but I am wondering what are good packages to use for the front-end / animation part? I used Graphviz to generate the base map (a directed graph), but it doesn't seem well suited for live animations.
Something like Hans Rosling's Gapminder (if it's even possible to do in real-time). Or should I be doing something similar and "recording" the data then playing it back? What packages should I consider in that case?
Gapminder
Currently using Rails 3.0, Ruby 1.9.2, Graphviz 2.28.
Here are 2 javascript libraries that may help. You could use ajax calls to your rails backend to populate their data. I'm unsure if D3 has mapping capability, but I believe Raphael does. As far as real-time, you'll have to check out their documenation. In Rails 4, I believe the streaming capability may benefit you as well, but I've not investigated.
Raphael
D3
What are the differences between the three Smalltalk web application frameworks?
Some starting points:
What is the sweet spot for each framework? in Which case would you use one or the other?
What are their weaknesses?
Which one has the cleanest URLs?
How do they handle Ajax?
Do they have some preference in their use of persistence?
I'm just trying to decide which framework is appropriate for each kind of application.
I can only answer for Seaside:
Target: Seaside targets complex web applications with focus on reusability and development productivity. There is automatic session state management and back-button support. The two free online books Dynamic Web Development with Seaside and Seaside Tutorial provide documentation.
Weakness: For RESTful URLs you have to do some extra work.
Clean URLs: For RESTful URLs you have to do some extra work, but it can be worth it (e.g. Pier).
AJAX: There are plenty of AJAX libraries integrated in Seaside (jQuery, jQueryUI, Prototype, script.aculo.us, ...). The integrations give you full access to these libraries from within Smalltalk. New libraries can be easily integrated, e.g. JQueryWidgetBox.
Persistency: Seaside is a web application framework, not a persistency framework. You can use whatever persistency solution fits you the best, e.g. GemStone, GOODS, GLORP, ...
Also see these other questions/discussions on StackOverflow:
What is the difference between Seaside programmming and other web programming
Is Seaside still a valid option?
I can say something on the Iliad side:
Sweet spot(s): It handles AJAX painlessly. For me, that was the turning point that made me switch to Iliad. Also, it's so small and non-bloated that you can read the whole code in a day and have a grasp on how it works.
Weaknesses: The community is also very small. This results in a lack of documentation, additional modules or pre-made widgets. OTOH, small communities tend to be willing to help each other more eagerly, so pretty much all your doubts can be solved by asking at the mailing list.
URLs: Well, since all calls in Iliad are AJAX by default, the URL stays clean the whole time.
Ajax: Yep. For free and by default. You just #markDirty a widget and it'll update automatically. Dependencies are as easy to define as sending #addDependantWidget: to a widget, so that when the first is marked dirty, both will be updated. Also, if the client doesn't have a javascript capable browser, all calls will fall back to regular HTTP requests automatically.
Persistence: No preference. Since the model is separated from the framework (I think this applies for the three frameworks) you can still follow the same guidelines you would for Aida or Seaside.
And for Aida/Web:
Sweet spots: Realtime web support out of the box, for both content websites and complex web apps, HTML5 and mobile support, web server included so it works immediately after installation, you can serve many virtual websites from the same image.
Weaknesses: lack of documentation, small community
URLs: clean REST-like URLs all the time, because Aida follows from the start the moto: every domain object can have its URL (also by Alan Kay) and domain object can even choose its URL by itself.
Ajax: Seamlessly integrated, you don't see it anymore, all is just there. To refresh some element on webpage you simply call e update. No need to know any jQuery or some other JavaScript. Same goes for realtime web apps as well. WebSocket protocol is default communication channel on supported browsers to exchange JSON messages between browser and Aida based server.
Persistence: Image based persistence with automatic snapshot every hour is turned on by default. Gemstone/GLASS support provided for the next step. Relational/other DB is a duty of domain level, if needed.
For more:
Comparison of Smalltalk web frameworks from Aida centric
perspective
ToDo example in Aida/Web shows the newest realtime web/HTML5
features, as part of Comparison by example initiative
For some persistency solutions for Seaside, there is a page. Most of the solutions there are independent of Seaside.