[PROJ] Pitching the proj project to Google's Geo team

[Luí­s Moreira de Sousa]

Hi Cameron,

the feedback so far has mostly in the negative sense, but perhaps that reflects the impact Google has  had in GIS. From my view point, a major contribution Google could have to the FOSS4G world would be to put the Mercator projection to rest once and for all. They are largely responsible for reviving it, when it is now wholly outdated. Instead of triggering a new wave of innovation in geography, web mapping technologies pioneered by Google in fact propelled a regression of several centuries in global mapping.

Google could contribute with the development/maintenance of modern map projections. For instance with the reverse projections of those that still lack it, or extend to the ellipsoid those that are still coded only for the spherical case.

Hope this makes sense. And good luck addressing the Google PTB. Regards. 


P.S.: I also second Greg's words.


--
Luís Moreira de Sousa
Pastoor Bruggemanlaan 21
6861 GR Oosterbeek
The Netherlands
Phone: +31 628 544 755
Email: luis.de.sousa at protonmail.ch
Mastodon: @luis_de_sousa at mastodon.social
URL: https://ldesousa.codeberg.page


Sent with Proton Mail secure email.

------- Original Message -------
On Sunday, August 21st, 2022 at 2:27 PM, Greg Troxel <gdt at lexort.com> wrote:


> Cameron Shorter via PROJ proj at lists.osgeo.org writes:
> 
> > Hi proj folks,
> > If you had one slide to pitch the proj.org project to Google's Geo team,
> > with the aim of getting Google to engage in the proj project, what should
> > be on that slide?
> 
> 
> Not what you asked, but I think that EPSG:4326 is a huge problem and
> needs to be fixed. By saying "WGS84" there is a vast amount of data
> labeled with an ensemble, and given the 2m fuzz, all the time-dependent
> things you are complaining about are not really wrong. Yes, they are
> actually issues and I get that, but for normal people's usage, only once
> you somehow define that the CRS of TMS layers is not "WGS84(ensemble)"
> but some ITRF(yyyy) that is non-ancient.
> 
> The usage of WGS84/4326 for TMS (which was a bug at the time) has bled
> into all sorts of things where people (who probably didn't really
> understand that WGS84(TRANSIT) exists collide with other people who
> think we need to treat 4326 as possibly containing TRANSIT and thus are
> allowed to use null transforms for meter-level shifts) just copied the
> phrase. It shows up in geojson and as the datum of OpenStreetMap.
> Because of this proj treats "NAD83(2011) epoch 2010.0" as equal to 4326;
> while technically defensible in a narrow sense it is in the modern world
> wrong.
> 
> Without fixing the definition of 4326 -- or fixing every standard that
> refers to it -- we end up in a world where we have to all say, outside
> of the specs, that 4326 doesn't really mean what it says, but means
> "Assume that the data is in the most recent realization when reading,
> but beware that it might be messy. When transforming to 4326, transform
> to the most recent realization. Accept write/read operations using
> different realizations as minor error sources (relative to the errors in
> the data before transforming), and if you don't like that, STOP USING
> 4326!".
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj