-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Display of mz:is_ceased always shows as 1 instead of reflecting actual data value #7
Comments
This is technically a bug in that the code here should also be checking for https://github.com/whosonfirst/go-whosonfirst-spelunker/blob/main/document/existential.go#L31-L35 Either way, this will require re-indexing things (which will at least be a good "wax on, wax off" exercise). Leaving this issue open until this is completed: |
One short-term solution would be to trap and remove |
Nice! I think I'm awaiting a deploy to verify fix... No hurry. |
The issue has not been fixed. These are just steps along the way. The real fix is going to be updating all the WOF records with bunk EDTF values: |
@stepps00 FYI this implicates whosonfirst-data/whosonfirst-data#1914 and crawling all the repos and updating EDTF values. |
Fixed with re-indexing (and changes to |
Verified, thanks! |
While viewing Faymont neighbourhood in France. I observed that the
mz:is_ceased
is always set to 1, even though nonsensically themz:is_current
property is still 1, and there is noedtf:*
details indicating the place is actually ceased. Browsing around it seems like this property is displaying on many records, including the country of France.Reviewing the src GeoJSON data and it seems like this property isn't present in the data for Faymont.
Why is this property being added? Should it be added? The counts are useful at the top of the new page, but I'm not sure about mixing in calculated properties and data properties in the main body of the page... or we need an indicator (like a background color?) to alert in these situations?
Is
mz:is_is_ceased
being imputed during page render? If so there's a bug in how it's being calculated.The text was updated successfully, but these errors were encountered: