Per the documentation here:
Can I replace:
map.data.loadGeoJson('https://storage.googleapis.com/maps-devrel/google.json');
with a local path such as:
C:\path\file.json ?
or must it be hosted on a server?
Thanks
In general, this used to be not allowed by design. It's a violation of the sandbox.
From Wikipedia -> Javascript -> Security:
JavaScript and the DOM provide the potential for malicious authors to deliver scripts to run on a client computer via the web. Browser authors contain this risk using two restrictions. First, scripts run in a sandbox in which they can only perform web-relatedactions, not general-purpose programming tasks like creating files.
However, it's now possible in current browsers using the FILE API specification.
This should in theory allow you to read it using the FileReader interface, although you might need to use something like JSON.parse() (or $.parseJSON if you're using JQuery) to then interpret it in the way you need. Lots more detail and examples of how to do this are here:
http://www.html5rocks.com/en/tutorials/file/dndfiles/
Related
This question comes from my poor understanding of how GDAL/OGR is supposed to work server-side, but before trying it I'd like to know if what I want is feasible with this library.
Basically, I am developing a webGIS application where the user should interact with a WFS. I'd like to give the user the possibility to download the data from this WFS as a format that the server does not provide as output so I need to convert it first.
I need the function ogr2ogr with the WFS driver to be able to convert the GML response of the server in (e.g.) Shapefile format.
My very basic question is: how can I call ogr2ogr which is installed on my server when the user click on (e.g.) a "Download" button?
My idea obvioulsy is to tie the onclick event with a JS function that calls ogr2ogr, but here my lack of knowledge in server-side web development does not le me go on.
Am I supposed to prepare a script (like a PHP) that internally calls ogr2ogr, or should I place the GDAL/OGR executables in a cgi-bin folder so that I can point and calling them with the required parameters?
I'd suggest investigating your server-middleware of choice; there's an excellent chance it supports OGR2OGR already if it's Open Source. The big two:
GeoServer has an ogr extension that can do what you want - https://docs.geoserver.org/stable/en/user/extensions/ogr.html
MapServer supports OGR too - https://mapserver.gis.umn.edu/output/ogr_output.html
Alternatively, you may want to consider investigating the WPS standard - but it's probably overkill if you're just changing formats.
Is there a geolocation API part of google closure (ultimately for use in ClojureScript) ?
I've been looking for it, but all I can find is something that looks like an old shim.
If there is none, is it because Google doesn't use that feature of web browsers (they find our location using other means), or because the browser API doesn't require that (already unified), and what would be the best alternative in ClojureScript ?
Nothing is in Closure for this right now. Generally, Closure only wraps these native APIs when there are cross-browser compatibility issues, is potential for a polyfill, or potential for improvement. I'm not personally too familiar with these APIs, but my guess is it's not in Closure because it's pretty standardized across the browsers that implement it.
The "shim" link you provided is what's called an externs file. It's used in conjunction with the Closure Compiler to avoid renaming certain properties. See this resource for more info.
I would like to create a new Chrome extension which will be distributed via Chrome store. I also would like to port some code parts of this extension to native code and to use Chrome's native client for it.
So my questions - is it possible to create solution which
comprises of two components - Chrome extension (e.g. can embed content scripts to third party sites like google.com) and native client (e.g. run some native code).
should have these two components be able to interact with each other e.g. via message passing (https://developer.chrome.com/extensions/messaging)
is distributed via Chrome Store as a single unit.
Thanks in advance.
There are two similarly named but quite different technologies.
Native Hosts. Those are separate programs, that cannot be distributed in the Web Store, and talk to your JavaScript with Native Messaging, a variant of standard Messaging API.
Native Client modules (NaCl/PNaCl). Those work like browser plugins, and they can be bundled with the extension.
Note that they are sandboxed from the system - the idea here is performance gain or non-trivial non-HTML UI inside the browser.
Inside your extension, you create an <embed> element that creates an instance of your native code module. JavaScript code can interact with (P)NaCl code with DOM events.
This page contains a guide on using NaCl in Chrome Apps, and mentions that the same applies to extensions. I haven't seen any better documentation, so you'll need to experiment and search around a bit.
First of all, I haven't started the implementation of the system I'm about to describe, as I didn't want to commit on implementing something I did not know if was possible.
So, what I'm trying to achieve is to build a chrome-app to download the audio from certain websites (e.g. youtube and soundcloud) using youtube-dl, post process it using ffmpeg and then upload it to a cloud service via some api. The reason I want to do it via a chrome-app is because I could do all the work on the client side (no need for servers) and I'd have the ability to insert javascript into the pages using content scripts, which would make the app pretty simple to use (I could create buttons such as 'download song' and stuff like that).
Although I have already read the documentation explaining the NaCl Technical Overview and some of the Application Structure, I still am not sure as to whether I would be able to make these calls via some C/C++ module or if I would get denied due to security reasons.
To summarize: considering that the user has the needed dependencies in his system (youtube-dl, python, ffmpeg and etc.), is it possible to make calls to third party APIs such as the ones described before via a chrome-app using NaCl ?
Thank you all in advance,
Chrome apps are normally sandboxed.
Less so than extensions - they can reach much more system resources via app APIs.
But still, what you mention is executing libraries / utilities out of browser, and it's not normally allowed.
(P)NaCl is tightly sandboxed in this regard. See this old question, it still applies: you can only use 3rd-party code that compiles into NaCl along with your app, not just link to a library. There are some library ports to NaCl, but it's not automatic.
Normally, a few years back you would use a mechanism like NPAPI to reach out and use a library out of browser. It's deprecated, and won't work anymore. In its place, Chrome offers a pipe-like (through stdio) connection to an external program called Native Messaging. You could use it to perform operations with system-level libraries and tools, but the downside is that you can't bundle the native host with your app, you'll need a separate installer.
I am writing a web application (I am a newbie), where the markup is created by XSL and XML transformations and the style is declared by css files and also some use of JavaScript. I need to create a web page that part of its content is the information on files in a specific directory in the file system.
Any ideas?
Are you talking about the client's file system, or the server's?
If the client's, what you are asking is basically impossible for security reasons without some specific browser plugins/extensions (like a java applet with the right access) - you probably don't want to get into that.
If you are talking about the server file system, you will need some sort of server side language to read the file(s) and return them to browser requests. The sort of things that do that are PHP, ASP.NET, Ruby on Rails, etc...also look into Server Side Includes - that may be sufficient for your needs.
Do you mean the client's filesystem or the server's filesystem? If it's the client's, these tools are inadequate (as access to the client's OS is severely restricted for security purposes). I think most people go with a Java applet for stuff like that.