What the difference between opencellid and mozilla location service?
Generally speaking both services collects "visible by device CDMA, GSM, UMTS, LTE cells, Wi-Fi hotspots, Bluetooth beacons at particular latitude, longitude". It is the place where GPS receiver is located at the moment of scanning, not exact base station or it's antenna sector place. When multiple measurements from different places around are available, it is possible to perform averaging of coordinates which is published (see below).
Things complicated for cellular networks
Most cell towers payloaded with multiple telecommunication equipment: 2G (GSM, GPRS, EDGE), 3G (WCDMA, UMTS, HSPDA)
Equipment divide area around in sectors and use directional antennas. When you go around base station (e.g. make a closed circle) phone will be connected to different sectors - antennas, which has different Cell ID / UTRAN ID. At this moment MLS and OCI can't aggregate this measurements in one base station. However for geolocation purpose more sectors means higher accuracy.
Meanwhile, databases contain exact positions of some base stations (or sectors?), check changeable==0 column in CSV dump.
Mozilla Location Service (MLS)
Collects cells and Wi-Fi measurements with libstumbler library which is incorporated in Mobile Firefox (collection is disabled by default) and Mozilla stumbler. Bluetooth beacons being collected some other way. Geolocation backend is called Ichnaea (it responsible for data exchange between MLS and OCI).
Looks like when user requests geoposition through API or Android MozillaNlpBackend, MLS query own collected data database, own copy of Opencellid database, GEO IP, and SkyHook partner. Collected Wi-Fi data is sensitive and used for online geopositon.
Published data: Public domain license. Daily CSV dumps of estimated cells location only (because of privacy: no raw measurements data, no wi-fi, no bluetooth beacons).
Opencellid (OCI)
Collects only cells (with 3-rd party software).
Published data: CC-BY-SA 3.0 license. CSV dumps of estimated cells location (updated in something around week) and raw measurement data. Free API key required.
No officially averaged MLS+OCI data published (I want be wrong here). Projects can't merge it because of license and privacy (Mozilla don't wont publish raw measurements). One can download CSV dumps and use it for offline geolocation. There are at least one succeed project for Android - LocalGsmNlpBackend for µg UnifiedNlp.
According to the Mozilla website:
The service incorporates aggregated cell data from our partner the
OpenCellID project. The OpenCellID data is provided under the CC-BY-SA
3.0 license and can be acquired from the OpenCellID downloads section.
The OpenCellID project puts a stronger emphasis on public data
compared to possible privacy risks, whereas this project has a
stronger emphasis on privacy. Please consider contributing to the
OpenCellID project if you do not agree with the privacy choices made
by this project.
Related
I have an app to create reports with some data and images (min 1 img, max 6). This reports keeps saved on my app, until user sent it to API (which can be done at the same day that he registered a report, or a week later).
But my question is: What's the proper way to store this images (I'm using Realm), is it saving the path (uri) or a base64 string? My current version keeps the base64 for this images (500 ~~ 800 kb img size), and then after my users send his reports to API, I deleted this base64 hash.
I was developing a way to save the path to the image, and then I display it. But image-picker uri returned is temporary. So to do this, I need to copy this file to another place, then save the path. But doing it, I got (for kind of 2 or 3 days) 2x images stored on phone (using memory).
So before I develop all this stuff, I was wondering, will it (copy image to another path then save path) be more performant that save base64 hash (to store at phone), or it shouldn't make much difference?
I try to avoid text only answers; including code is best practice but the question about storing images comes up frequently and it's not really covered in the documentation so I thought it should be addressed at a high level.
Generally speaking, Realm is not a solution for storing blob type data - images, pdf's etc. There are a number of technical reasons for that but most importantly, an image can go well beyond the capacity of a Realm field. Additionally it can significantly impact performance (especially in a sync'ing use case)
If this is a local only app, storing the images on disk in the device and keep a reference to where they are (their path) stored in Realm. That will enable the app to be fast and responsive with a minimal footprint.
If this is a sync'd solution where you want to share images across devices or with other users, there are several cloud based solutions to accommodate image storage and then store a URL to the image in Realm.
One option is part of the MongoDB family of products (which also includes MongoDB Realm) called GridFS. Another option is a solid product we've leveraged for years is called Firebase Cloud Storage.
Now that I've made those statements, I'll backtrack just a bit and refer you to this article Realm Data and Partitioning Strategy Behind the WildAid O-FISH Mobile Apps which is a fantastic article about implementing Realm in a real-world use application and in particular how to deal with images.
In that article, note they do store the images in Realm for a short time. However, one thing they left out of that (which was revealed in a forum post) is that the images are compressed to ensure they don't go above the Realm field size limit.
I am not totally on board with general use of that technique but it works for that specific use case.
One more note: the image sizes mentioned in the question are pretty small (500 ~~ 800 kb img size) and that's a tiny amount of data which would really not have an impact, so storing them in realm as a data object would work fine. The caveat to that is future expansion; if you decide to later store larger images, it would require a complete re-write of the code; so why not plan for that up front.
For some reason I need to know difference between VAST,VPAID and VMAP.
I know both are video ad deliver tags, these are following IAB standard, but I need to know clear difference between these three.
Any help is appreciated.
VAST, VMAP and VPAID solve different challenges when it comes to showing advertisements in a video player.
Short answer
VAST describes ads and how a video player should handle them. (more or less)
VPAID (deprecated, see update below) describes what "public" communication (methods, properties and events) an executable ad unit should at least implement/expose, so the video player can communicate with the ad unit in an uniform way and control it.
VMAP describes when an ad should be played.
In more detail
VAST (Video Ad Serving Template) is used to describe ads and how a video player should handle these. Note that the concrete implementation is up to the video player itself. There are three types of ads:
A linear ad is an advertisement video rendered inside the video player.
A non-linear ad is an advertisement overlaying the video player. It is mostly a banner image, but it could also be HTML or an iFrame.
A companion ad is an advertisement rendered outside the video player. It is mostly rendered alongside a linear or a non-linear ad, as they can complement each other (hence the name).
More examples of cool stuff VAST describes:
When an ad is allowed to be skipped (for linear ads)
What URIs should be pinged for tracking
Sequence of ads (ad pods) that should be played together
Different resolutions / codecs for same advertisement
VMAP (Video Multiple Ad Playlist) is an optional addition allowing you to specify when an ad must be played. Via VMAP you can indicate whether an ad is a pre-roll (ad before the content), a mid=roll (ad somewhere in the content) or a post-roll (ad after the content). VMAP can also refer to multiple VAST files to be played at different times.
VPAID (Video Player Ad Interface Definition) is a specification describing what an executable ad unit (= interactive ad) should at least implement and expose for public communication/control. This allows the player to delegate instructions to the ad and yet keep control over it (e.g. starting, pausing, finishing it...). That way, a player can give instructions (methods) and request information (properties). The ad itself can also dispatch events indicating that a certain action has happened (e.g. volume has changed, ad has been skipped, ad has been clicked...).
It is interesting to note that VPAID has two versions: version 1 is only Flash, while version 2 is only JavaScript.
How these three connect with each other
VMAP refers to a VAST, but never to another VMAP.
VAST can contain its ad data internally (Inline) or refer to another VAST (Wrapper), but never to a VMAP. VAST describes ads. Some ads can be executable (interactive).
If an ad is executable then it must implement VPAID so the player can cooperate with it.
Update June 2019
Quite a few things have changed since this answered was submitted. In VAST 4.1, the IAB deprecated the VPAID specification in favor of an upcoming specification. VAST 4.2 (currently in public comment phase) formalized the successor of VPAID:
for ad verification, the Open Measurement SDK should be used
for interactivity, the SIMID (Secure Interactive Media Interface) specification should be implemented.
IAB Digital Video Suite
VAST(Digital Video Ad Serving Template) is an XML with <VAST> root where the main part is MediaFile tag with a url to video file. IAB
VPAID(Digital Video Player-Ad Interface Definition) is extension of VAST where MediaFile tag contains type="application/javascript" apiFramework="VPAID" attributes which allows to define a JS source to be handled. SpotXChange, Innovid
VMAP(Digital Video Multiple Ad Playlist) - is an XML with <vmap:VMAP> root and is used to describe a schedule for VAST files( pre/mid/post roll)
Google IMA Examples
[MRAID]
I am trying to map the properties of a medical device as described by a sequence of OBX segments in a PCD-01 message to FHIR resources. The properties described in the PCD-01 message are
the device type (such as a blood pressure cuff) (found in FHIR Device
resource)
the manufacturer name and model number (found in the FHIR Device
resource)
the production specifications (found in the FHIR DeviceComponent
resource)
properties such as time capabilities (found in the FHIR DeviceMetric)
I would expect that the logical way to do this would be to populate each of these resources with the data from the said OBX segments and then "link" them together by making the DeviceMetric a contained resource of the DeviceComponent which is a contained resource of the Device. However, a contained resource cannot contain further contained resources so I need to include two contained resources in the Device resource.
However, the example for the DeviceComponent at
http://www.hl7.org/fhir/2015May/devicecomponent-example-prodspec.json.html
shows the Device a contained resource of the DeviceComponent, exactly backwards of what I would expect. How are these resources supposed to be used? I cannot use any single one of these resources to describe all the properties of the actual device, the real difficulty being that the manufacturer and model names are not in the same resource as the production specification information.
Also, if the Device type identifies that the device is a blood pressure cuff, what does the DeviceComponent type indicate? There really is no 'component' in this case, the device is a stand-alone BP cuff and nothing else, I am just forced to use the DeviceComponent resource in order to describe the production specification values.
Any help on this would be greatly appreciated!
Thanks Ewout for your very well explanation.
To Brian: As you mentioned IEEE 11073-20601 in one of your comments, may I make an assumption that you are only dealing with MDS and Metric as the DIM model for your blood pressure cuff?
Thus, to describe the blood pressure cuff observation (PCD-01 message), your resource of interest are the following:
Device: to describe the device type (preferably using nomenclature as defined in IEEE 11073-10101), manufacture and model number, udi, etc. This resource is created once, and will live through the lifetime of the device unless there is a change with location/organization/patient.
DeviceComponent: to describe the MDS where you can populate production specification, operational status of the device, etc. This resource would have the same lifetime as the device resource unless there is a change with software version, hardware version, or operational status for example.
DeviceMetric (x3): to describe each metric (systolic, diastolic, pulse) including type (preferably using nomenclature as defined in IEEE 11073-10101), unit (preferably using nomenclature as defined in IEEE 11073-10101, but UCUM is fine), identifier (metric unique identification that is assigned by the device, for example, handle ID), and measurementPeriod (if the device happens to repetitively taking measurement at a specified period time, for example, every hour). Same lifetime like DeviceComponent unless there is the change in unit or measurement period.
Observation (DeviceMetricObservation profile): to describe the actual measurement. (In PCD-01, we used OBX-4 to describe the c-tree path that link the observation to the actual metric in the tree. For FHIR, we use device element to describe the external reference to the DeviceMetric)
I would not recommend to use contained resource. I think we should probably create all Device/DeviceComponent, and DeviceMetric resources ahead of time, cache their links and used those as external references. For example, Device resource will be created first, then DeviceComponent whose source element contains the external reference to the Device resource, then DeviceMetric resource whose parent element contains the external reference to DeviceComponent and source element contains the external reference to Device. Now that we have a somewhat well-organized containment tree setup using those resources and links, whenever the device produces a new measurement, we only to create the observation resource, setup the link to DeviceMetric, and that should be it.
Please let me know if you have further questions. Thanks
"the Device a contained resource of the DeviceComponent, exactly backwards of what I would expect"
This is the way that the resources are defined - DeviceComponent refers to Device as a source, rather than Device listing it's components. I'm not sure why they are defined that way - I'll ask the committees (Orders/Obs and Devices) to comment.
I would think that if the Device is a blood pressure cuff, it has a single component that carries the values. That's not the most obvious solution, but it's certainly how things have developed over the years in the PCD space.
The physical composition of a Device is done by the DeviceComponents pointing to their "parent" component using DeviceComponent.parent, e.g. channel to VMD and VMD to the MDS. All components point to the "logical" Device they belong to, using DeviceComponent.source.
In this model, the "Device" is the "administrative" resource for the device (it does not change much and has manufacturer information etc.), where as the DeviceComponent models the physical part, including operation status and is much more volatile.
If you want to express which logical device your observation came from, you can just use Device, if you need to be more specific observation can point to DeviceMetric (which is really a kind of DeviceComponent).
My app shows a map where locations (or Markers) are dynamically loaded via an ajax (and database) request after every map Bounds changes.
I'm convinced that this solution is not scalable : at the moment, Europe area shows a total of 10 markers.
If the database grows and I display for instance 1000 locations, that means 1000 rows would be returned to the user.
This is not a JS / UI since I use the MarkerCluster plugin and I avoid the redraw of loaded locations's markers.
I made some tweaks :
- Delay the Ajax request thanks to an Idle gmaps event
- Increase the minimal zoom level, so the entire world can't be displayed.
But this is not enough.
There are lots of ways to approach this but I will just put here the two I think are most appropriate from your question.
First is to really control from your web app what information is asked for and when. You could write this all yourself in javascript and implement caching techniques ect. There are a number of libraries out there that do most of this work for you though.
I would recommend one of the following:
OpenGeo SDK
OpenLayers
GeoExt
Leaflet
All of these have ways of controlling local caching, when to get the data and what data is gathered from the server. Most of them can also be extended to add any functionality that is missing. The top two I know support google maps (as well as a number of others) as well.
If you need to add even more control over your data locally you could even look at implementing something like PouchDB. I think this is more suited to mobile applications or instances where the network connection is either really slow or intermittent.
This sort of solution should be able to easily handle 1000's to 10000's of features with 100's of users.
If you are really going to scale up to 100000's to 1000000's of features with 100's to 1000's of users then I would suggest adding a tile server to the soloution above. The tile server will sit between your web application and your data base. Most of them have lots of caching settings and optimistions for dealing with large datasets and pushing them out to a client. Because they push out tiles rather than features the data output remains reasonably constant even as the number of features grow. The OpenGeo SDK and Openlayers libraries I mentioned above can work really well with any of the following tile servers:
GeoServer
Mapserver
MapGuide
Quantum GIS Server
If you are reluctant to do any coding there are some offers that work out of the box for enterprise environments. They are all expensive and from your question I think they are probably not what you are looking for.
I live in city X, but when i try to get my location via ip all the "find location by ip" websites point to city Y. Some ads "Hang tonight with girls in city X" they precisely know my location. How this is possible? Exists some kind of data, a database with ips which those ads site have?
There is no such thing as precise location from an IP... the quality of any such service never reaches 100%... as you write there are several different databases out there - each with some very good and rather weak spots... some databases are updates regularly, some aren't etc.
Those ads use databases which just happen to have their weak spots somewhere where you don't live...
I have never come across any such service that told my city correctly (although it is not small)... they are off by 20-400 miles sometimes even claiming that I am in a very small city far away...
Mostly you can tell the country correctly... although even that can be fooled by proxy/VPN/anonymizer...
For some insight see:
http://www.private.org.il/IP2geo.html
http://ipaddressextensions.codeplex.com/
http://software77.net/geo-ip/
http://jquery-howto.blogspot.com/2009/04/get-geographical-location-geolocation.html
A rather special and different case is this:
One rather precise way to tell the location is when you use a device (usually mobile phone)... these have several sources available (like tower locations, like GPS)... another point are the databases Google and Apple build by using anonymized from phones... they basically aggregate data regarding tower, GPS and WLAN HotSpot/access points reachable... this way they can (with a small margin of error) tell from the WLAN data (like MAC address) the location...