Crowdsourced Map Data Collection - Key Questions to Answer

Heather · 10-02-2009, 10:32 AM

Here are a few key questions to answer:

Q1: Will the Crowdsourced Map Data Collection App, created by lambospirit, deliver data that will be readable and useful, lending itself to analysis and the creation of maps? Do we need to add or remove something from the app?
See sticky on Collection app to get details on how it works.

Q2: What should the process be for validating data streams, to ensure that the data being uploaded is real and useful?

Q3: How many people do we need uploading gps tracks and how much data do we need to begin to generate maps?

Q4: How long will it take to create maps that can be useful?

Q5: Who else should we get involved? Universities, organizations, etc. Currently we have only informed Open Street Map of the Crowdsourced Maps project.

lambosprit · 10-02-2009, 12:20 PM

Quote: Originally Posted by Heather

Here are a few key questions to answer:

Q1: Will the Crowdsourced Map Data Collection App, created by lambospirit, deliver data that will be readable and useful, lending itself to analysis and the creation of maps? Do we need to add or remove something from the app?
See sticky on Collection app to get details on how it works.

If its in the gps messages I can add it.

I depends on what you're trying to achieve. If its just mapping then lat, long and maybe altitude is all you need. The big thing seems to be how often you sample these points (currently once every 100 metres.)

If you're after traffic reports, as some suggested, then some kind of real time update and speed collection would be required. All doable in my app but adds complexity, cost and not much benefit until people are really using it.

Other important data is the street data, road names, numbers, speed limits etc. I have started research on this and will be coding once I've made the tracker robust and easy to use.

justchat_1 · 10-02-2009, 01:29 PM

Quote: Originally Posted by lambosprit

If its in the gps messages I can add it.

I depends on what you're trying to achieve. If its just mapping then lat, long and maybe altitude is all you need. The big thing seems to be how often you sample these points (currently once every 100 metres.)

If you're after traffic reports, as some suggested, then some kind of real time update and speed collection would be required. All doable in my app but adds complexity, cost and not much benefit until people are really using it.

Other important data is the street data, road names, numbers, speed limits etc. I have started research on this and will be coding once I've made the tracker robust and easy to use.

Alright after reading heathers description...i think this project has some potential.
Q1:
But figuring out exactly what its goal is should be the first step - and really will help answer alot of the other questions. I think real time traffic is an unrealistic goal given the userbase. Just turning this into an easy way to contribute data to OSM, on the other hand, is very doable and would probably grow rather quickly. Another option is historic traffic (or whatever the proper name for it is). You collect average speed data for each section of road storing it on a per half hour per day of the week thing. This allows you to know that for example emon through fri from 730 to 930 theres traffic on road x...or every sat afternoon on road y, etc.

Either way, data storage needs to change - the raw xml files idea is not scalable at all...xml should be used for transport never for storage in any large project.

Q2:
Data validation is relatively easy to do...you set error conditions and check for them on upload in addition to the in program checking (ensuring a 3d gps lock before data is taken, minimum deviation of x meters, etc.). If more then x errors/number of data points you throw out the whole entry otherwise you filter +-5 waypoints of the bad data. This allows for example a gps jump when signal drops going under some heavy trees to be filtered out, but a defective device or spam to be completely dropped.

Q3,4&5 - Depends on Q1

lambosprit · 10-03-2009, 07:27 AM

my app uses xml purely to get the collected data to the ftp site. How its stored there is up to the project.

GPS accuracy is fairly easy. All gps recievers work out their own accuracy and return it with each gps message so the only thing required is to set the level we feel acceptable in the code. A value of <6 seems to be the correct one.

As for spam and malicious tracks that another question but to start with i suspect you could assume people are honest as if you're going to try this then you're not going to be doing it to scupper it.

justchat_1 · 10-03-2009, 01:58 PM

Quote: Originally Posted by lambosprit

As for spam and malicious tracks that another question but to start with i suspect you could assume people are honest as if you're going to try this then you're not going to be doing it to scupper it.

That was just an example...but there are plenty of legitimate reasons data could be unusable and should be thrown out. For example, a gps receiver thats not functioning correctly. Checks when you import data really aren't difficult at all...especially if its being imported into an sql database.

User Name		Remember Me?
Password