Our next community call is coming up this Thur. 2/21 at 12PM est.
We'll be talking about Dynamic Proof of Location and The GeoPickle - a testing rig consisting of Raspberry Pis and servers that acts as the first real world simulation of zone anchors.
Join us to learn why this is big step forward for DPOL:
https://goo.gl/forms/U1mCA2krJbrL15y93
My friend is having an issue with the challenge that he's worried about - https://discourse.foam.space/t/incorrect-street-numbers-in-barcelona-slowmov-challenge/575
Are you storing addresses in the IPFS/blockchain? Or you are storing geohash and then getting it from mapbox?
Seems like there's an issue with UI/UX
https://discourse.foam.space/t/incorrect-street-numbers-in-barcelona-slowmov-challenge/575/8
If I understand correctly you search for the correct address, but it autofills the card with the wrong address? If so, that is a newly discovered issue that we have not come across before. It is a Mapbox issue and seems that their street address and geocoding systems are not perfectly aligned.
Ultimately, it is the responsibility of the Cartographer to verify all information before hitting submit ā in this case by doing so the FOAM Map data would be more accurate than what is coming from the Mapbox base map. I will bring this to developer team to see how it can be addressed. One way may be to make more explicit in the card to review the address field.
Given the documentation around how this occurred, I think it is a good opportunity for token holders to weigh in and vote on the point. If it survives the challenge you could manually remove and re-add ā in any case thanks for bringing this up for discussion and attention to the issue!
could foam use something like a zk-rollup for on chain data? they seem incredibly powerful constructions.
https://medium.com/matter-labs/introducing-matter-testnet-502fab5a6f17
TLDR, SNARK based merkle root onchain avoids data availability prob of Plasma