2

I'm working on a Esri Silverlight Web API app and wondering the best way to handle the import of local spatial vector data files. Sometimes these will be your standard shape file but often these will be in vendor specific proprietary file formats that will have to use special API's to parse out the data within them. My question is whether it would likely be a better practice to handle the data conversion on the server side vs. attempting to do it on the client side?

Improve this question
3
  • Is your silverlight running in Out of Browser mode with elevated permissions? Can you set a reference to the assemblies provided by your special API's without visual studio complaining?
    – Kirk Kuykendall
    Apr 22, 2011 at 16:23
  • This is still in the planning stages so making it a Out of Browser app is a possibility but not sure that will even matter since we will likely be using SL5. Also unsure on the assembly reference problems but that could likely be a problem.
    – wilbev
    Apr 22, 2011 at 16:55
  • 1
    +1 after thinking about this a bit, I've decided to upvote this. It would be useful to be able to simply preview relatively small files that have been published on the internet without loading them on a server. (Dwg files of subdivision plats especially).
    – Kirk Kuykendall
    Apr 22, 2011 at 22:47

1 Answer 1

Reset to default
2

Doing that kind of thing server side would be a more scaleable option. Using your app to upload that data into ArcGIS Server DataInterop or Safe/FME which can them publish to a webservice for display on your app is the easiest to maintain.

As then you are removing the dependency of your App speaking all these differnet formats and it just is needed to push up and display the data; let the backend handle the data format or conversion.

You can even if you want a lowest cost option look at some of the OSGeo stuff; host that on a server, then write some webservices that you call from your SL app to push up to them; reshape the data to be overlayed in your front end.

Silverlight is really just a Rich-UI tool; you don't want to make it too burdensome on the client machine; much like a web-app its really geared to display rich information and not be a replacement for dedicated tools.

Improve this answer
3
  • thanks for answer. I completely agree with what you're saying and agree it is probably the best approach. My only worry with doing it server side is one of performance and speed as well as the need to be connected. Do you think doing it server side could be similar in speed as doing the conversion client side? If so, the only draw back would not being able to do it when disconnected from server.
    – wilbev
    Apr 22, 2011 at 22:04
  • Doing it client side means you will also have to support all the needed dependencies on each of your users machines. Which starts to negate the benifits of SL to begin with. SL is first and foremost just a UI; to do rich presentation of data; less about being a complete SDK to replace dedicate thick-client apps. It that is your direction then you might be better off just using .Net to build a App.
    – D.E.Wright
    Apr 23, 2011 at 23:54
  • I completely agree once again with what you are saying. Crazy to try to support everyone client side. It's good to get your feedback, thanks.
    – wilbev
    Apr 24, 2011 at 6:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.