Actually, that's exactly it. The idea of using barcodes to track locations
was to have a trigger which would signal that a given location was owned by
a new shop, so the record for the previous shop should be purged from the
You are right, otherwise, that business registration is a good UUID.
I've been thinking for the time being we may capture business
registrations along with the rest of the data. Then, on following runs, we
would contrast the new data with the older version. If a business ID
repeats that shop would be considered to have a history in the database. If
it doesn't it would be a new one. If it was there before but wasn't
encountered in this second run, it would be a sign the shop is gone and we
should deactivate it.
I realise this solution is not very elegant and I'm worried about how
robust the resulting data actually is.
@Eric, I also think it seems more and more like we're finding ourselves
moving down the road to using a fuller GIS solution. I've been looking at
@Tapan, I'm also intrigued by your comment. I looked at
http://localground.org/ but for now there isn't a lot of info there.
On Thursday, 31 May 2012 11:45:55 UTC+8, ニコノコ wrote:
I suppose, just like in most cities, you'd have shops that are required to
have business licenses to operate. That'd be their UUID. It's extremely
unlikely for these not to be unique.
Your idea of passing barcodes to the next tenant is strange, unless your
tracking what's found in a particular geopoint rather than what business is
at that particular geopoint.
If it's impossible to assign them a unique identifier assigned to each
respondent, I'll play around with the geopoint location to compute the
distance and then see if they share the business name within a certain
radius to check if they've been surveyed before. Again, this is not within
the scope of ODK, which is a "data collection tool".
Could you elaborate a bit on "local ground". I haven't heard of this
On Thursday, May 31, 2012, Christian Mondorf wrote:
We're trying to have a continually updated map of traditional trade
outlets, so mostly small "mom and pop" shops, and have them geocoded
because addresses here are a bit of an uncertain science sometimes.
We've thought of giving people barcodes which could be scanned on
following visits, but this runs into two problems. The first is that the
person we speak to on the first visit may be gone or have lost the code
when we return. We've considered stickers but worry they may not be as
permanent as one hopes.
The second problem, of course is that such shops close down or are
replaced, and handing over the barcode to the new tenants is probably the
last thing on their mind.
On Wednesday, 30 May 2012 18:28:34 UTC+8, ニコノコ wrote:
What are you tracking? Or, what's your objective here?
Personally, I don't consider an address as ideal unique identifier (i.e.
several corporations could share the same physical address but are
separate juridical entities.) For tracking repeated surveys of same
respondents, the ODK case study I've read assigns a unique ID for each
respondent (read through a QRcode).
On Wednesday, May 30, 2012, Christian Mondorf wrote:
Thanks to both of you, you've both made some very interesting points.
Unfortunately the business registration number doesn't really solve our
problem since a change in the business would result in the new business
occupying the address having a new business number.
I know the obvious solution is to use the address as a unique identifier
but this project was started as a way to circumvent the problems with
working with addresses in Malaysia outside of the capital..
On Wednesday, 30 May 2012 10:36:08 UTC+8, ニコノコ wrote:
I would assume that the business registration number is unique to each
enterprise. It's outside the scope of ODK, but in your database, you could
consolidate your records based on that field (or some other uuid).
On Tuesday, May 29, 2012, Christian Mondorf wrote:
I've just realised I didn't explain the problem properly.
We are identifying our stalls or shops by their name, location, address,
and business registration number. The problem comes from the fact that
addresses are very uncertain here, with streets often being known by
several names and the numbering being haphazard. The name and business
registration cannot be used as keys because if the business changes then so
do those two attributes. Rather, those are the attributes we need to know
how to change.
Finally, geolocation isn't accurate enough, so no each subsequent visit
we'll get a slightly different reading.
So the problem, then, what absolute attribute could we use to identify our
locations, which we could use to find them in the database to make changes?
On Tuesday, 29 May 2012 13:40:43 UTC+8, Christian Mondorf wrote:
I am wondering about how (and if) people have updated their databases bu