Yes, they deprecated the CRS field and the current state of geojson handling libraries is pretty messy as a result since geojson does not have versioning!

If you have old geojson in a different projection, will your library respect the crs field or will it simply misinterpret your data?

Wondering if anyone could shed light on the decision to remove it as a standard when projection seems to be a critical part of GIS.

Coordinate systems and projections are one of those deeply complicated truths that makes such a headache in GIS. I still shudder at all the pain in school and at previous jobs dealing with inconsistent datasets.

It seems like they decided to just opt out of trying (see the yellow box in section 4): https://stevage.github.io/geojson-spec/#section-4

I think they should have completely backed off from touching on projections and datums in the format altogether. Ie. Something like, “coordinates are 2 or 3 tuples where the values in order correspond with easting/long and northing/lat and elevation/altitude. See metadata for agreed upon units and CRS/projection semantics. It is strongly encouraged to standardize on WGS84 when encoding data with an earth-resolvable datum.”

Because GeoJSON otherwise works fine for indoor spaces, video game spaces, fictional lands, other celestial bodies, etc. You just have to educate on the idea that there’s more to data compatibility than it being GeoJSON.

Not everywhere that python is run has access to pip. Sshing into some locked down remote machine and needing to debug some script is a use case that comes to mind.

Isn’t the browser inspector more than sufficient? You get the interactive object inspector in the console, live expressions, log points etc.

For node you it’s possible to hook it up with the browser inspector as well

Don't know why you're downvoted, but browser devtools have the best object inspection around. I miss them all the time when coding Python.

Hooking devtools with Node is possible but could be a lot nicer.

Something interesting I realized about their choice of name - S7.

1. It's a combination of S3 and S4 obviously.

2. It's also linked to another OOP system called R6. Interesting how it's a step forward one way (6->7) and a step 'backwards' in another way (S->R).

To me it shows the philosophy of not creating something entirely new but improving the existing systems quite nicely!

I actually think this "multi-tiered" system of OOP is quite cool, when compared to languages that stick OOP in your face upfront.

1. Basic users don't even know it's there, they're just calling regular functions.

2. S3 in base is super simple to understand and easy to extend the first time you need to implement your own summary.

3. Full blown OOP with slots and methods is available when you really need it (rare for a user and not library author imo, lists and S3 are sufficient for most things).

The big issue I see is the incompatibilities in the various systems making this "ramp up" not so smooth. But it looks like that's what S7 is trying to address so that's cool.

Yes, though the languages do not support it explicitly you can simulate lazy evaluation by wrapping all your arguments in closures. This way they won't be evaluated until called within the function body.

Sidenote, the evaluation model of python can be surprising. List comprehension will create implicit function scopes that can trip you up.

I too am a Tidyverse shill. Hadley Wickham truly did an amazing job designing the whole ecosystem and API. I personally haven't encountered another API that has given me the same feeling of mastery and empowerment - just the correct blend of expressiveness, cohesion and ease of use.

Of course this is partly attributed to R's great DSL capabilities and making documentation first class. But I've definitely seen terrible APIs in R too.

Wonder if anyone else has had a similar experience with another ecosystem? (Regarding API design)

I'm in a similar boat. I have to use a 3rd party component library written in web components for our react app (esri/calcite-components) and it's a huge pain because * You can't override styles except what is exposed through css variables * They often encapsulate some internal logic which I can't control from React (tbh this could happen with a React library too)

Seconding NewPipe. Though recently it's been unable to load comments and the error banner keeps popping up as a result (no comments may actually be a plus?)

I still use the regular Youtube app for shorts but NewPipe is definitely a better experience overall. My main gripes with the official Android Youtube client: - They made it so annoying to choose your video resolution (Seriously, who tested this and found it better than the old method?) - I can accept not being able to play in the background, but if you lock your screen while in fullscreen mode and then unlock it, there is a very noticeable lag before the app exits fullscreen mode, and in this period you cannot resume playback.

Youtube seems to be doing some A/B testing with the comment system which has made proxies like Invidious and yt-dlp/Newpipe unable to load comments. There is a patch for Invidious [1] which solves this problem but it is not in master yet. I tested it on my own instance and it does solve the problem.

[1] https://github.com/iv-org/invidious/pull/4576

Inline styles don't work with a strict CSP. Have you ever had to work with such a restriction?

A CSP can be configured to disallow external stylesheets too. I don't see how that's particularly relevant. But obviously if for some reason a CSP was configured as such, and I had no power to change it, I'd work around it.