A few comments: Discussion is in thread https://lists.osgeo.org/pipermail/discuss/2016-August/thread.html#16505 "Detect and define the coordinate system of gis data with no projection information automatically".
This discussion mentions epsg.io and spatialreference.org and why the latter is not reliable http://osgeo-org.1560.x6.nabble.com/EPSG-32661-clarification-tt5283591.html Then something about SRID values 0 and -1. The GeoPackage standard defines them as 0=undefined geographic system, -1=undefined Cartesian system and I suppose it is derived from an ISO standard "ISO/IEC 13249-3:2011 Information technology — SQL Multimedia and Application Packages - Part 3: Spatial (SQL/MM)" This is the section from the GeoPackage standard: Req 11: The gpkg_spatial_ref_sys table in a GeoPackage SHALL contain a record for organization EPSG or epsg [B3] and organization_coordsys_id 4326 [13][14] for WGS-84 [15], a record with an srs_id of -1, an organization of “NONE”, an organization_coordsys_id of -1, and definition “undefined” for undefined Cartesian coordinate reference systems, and a record with an srs_id of 0, an organization of “NONE”, an organization_coordsys_id of 0, and definition “undefined” for undefined geographic coordinate reference systems. -Jukka Rahkonen- ________________________________________ Lähettäjä: Michaël Michaud <m.michael.mich...@orange.fr> Lähetetty: 4. syyskuuta 2016 20:58 Vastaanottaja: jump-pilot-devel@lists.sourceforge.net Aihe: Re: [JPP-Devel] Add SRID and units to Task Hi manfred, Can you give us a reference to this discussion ? Will this database have a distinct goal compared with http://spatialreference.org/ ? Michaël Le 04/09/2016 à 18:59, manf...@egger-gis.at a écrit : > ... is someone of you a member of this mail list: disc...@lists.osgeo.org > > Last week we discussed a solution of a central web-database where all > coordinate systems are registered. This database should be promoted by OSGeo. > > Maybe i can send you the mail traffic? > > Best regards, > > Manfred > > -----Original Message----- > From: "Michaël Michaud" <m.michael.mich...@orange.fr> > Sent: Sunday, September 4, 2016 12:48pm > To: "OpenJump develop and use" <jump-pilot-devel@lists.sourceforge.net> > Subject: Re: [JPP-Devel] Add SRID and units to Task > > ------------------------------------------------------------------------------ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > Hi Peppe, > > Thanks for your new explanations and references, > > For EPSG codes from 6,000,000 - 6,999,999 : I finally agree with you. > These codes are deprecated but "remain in EPSG dataset". > > Michaël > > Le 04/09/2016 à 16:11, Giuseppe Aruta a écrit : >> Hi Michaël >> thanks for the explanation. It was a bit confusing (not only for me) >> when studing this topic >> -------------------------------- >> EPS codes >> >> http://www.ihsenergy.com/epsg/geodetic2.html >> reading this page it seems that EPSG code range are: >> 0 - 32767 and 6,000,000 - 6,999,999 (since ver. 6.6) >> >> --------------------------------- >> >> regarding SRID vs CUSTOM, >> >> According to Wikipedia SRID "is a unique value used to unambiguously >> identify projected, unprojected, and local spatial coordinate system >> definitions" >> https://en.wikipedia.org/wiki/Spatial_reference_system#Identifier >> (In that case it seems to be the equivalent of ESRI WKID >> (https://developers.arcgis.com/javascript/3/jsapi/spatialreference-amd.html). >> >> while >> >> CUSTOM, as I understood, is a local projection >> (http://wiki.gis.com/wiki/index.php/Custom_projection). >> ESRI defines CUSTOM codes (200000-209199) which are outside the >> "official ones". >> EPSG uses a different "authority acronym" SR-ORG to define them so >> there are SR-ORG/ESRI overlaping codes. >> Thi is a new proposal, that needs to be inspect, anyhow >> >> a) recognized as integer >> UNKNOWN: -1, 0 : UNKNOWN >> EPSG: 1-32766 [ or 1026-32766(**) ] and 5999999-2147483647 >> ESRI: 33000-200000 : ESRI registry >> FranceGéoportail: 310024802 to 310915814 - FranceGéoportail , not >> recognized by EPSG, the info seems quite outdated >> (http://www.wms.lautre.net/projgp.html) >> >> SRID: other (no intention to define whether the codes are defined by >> users (CUSTOM) or not, no intention to define if it belongs to other >> authority that EPSG/ESRI) >> b) recognized as string >> I would let it blank, even if we only have INGF codes. >> >> Peppe >> >> (*) according to this page (http://www.wms.lautre.net/projgp.html) >> (**) http://www.ihsenergy.com/epsg/geodetic2.html >> >> 2016-09-04 12:54 GMT+02:00 Michaël Michaud >> <m.michael.mich...@orange.fr <mailto:m.michael.mich...@orange.fr>>: >> >> Hi Peppe, >> >> Just wonder why you want to retrieve authorities from srid ? >> If it is important, why not adding authority in the srid.txt file ? >> It is quite impossible to get authority from code as codes are >> supposed to be unique for a single authority only. >> By chance, EPSG is so well-known that most implementions (ESRI, >> GeoTIFF, PostGIS) take care to use the same code for the same CRS, >> and add new CRS in a specific range of codes unused by EPSG. But >> every implementor has its own rules, and what I've found is very >> confusing. >> >> negative srid : unused, except -1 which used to mean UNKNOWN in >> postgis 1.x >> 0 : means UNKNOWN in GeoTIFF and PostGIS 2.x >> 1-2000 : unused but valid EPSG codes for CRS >> 2000-32766 : EPSG codes also used by ESRI (WKID), PostGIS, GeoTIFF >> for the same CRSs... >> In GeoTIFF, projected CRS codes seem to start at 20000, >> but smaller EPSG codes exist in EPSG database >> note : SR-ORG codes (1-9000) are overlapping EPSG code range >> 32767 : user-defined in GeoTIFF implementation ( don't know what >> is the difference between user-defined and private-user >> implementation ?) >> 32768-max : >> GeoTIFF : 32768-65535 : private user implementation >> ESRI : 32768 - 33000 : unused ? >> ESRI : 33000-200000 : ESRI authority >> ESRI : 200000-209199 : ESRI Custom codes >> PostGIS : 32768 - 910000 : ? (can be used for ESRI WKID ?) >> PostGIS : 910000 - 998999 : Custom codes >> SpatialReference : EPSG:61000000-69000000 (superseded, not >> referenced in EPSG database) >> >> GeoTIFF Projection and ProjCoordTrans are other types of beast. >> They do not define a Coordinate Reference System. >> >> What I would keep : >> -1, 0 : UNKNOWN >> 1-32766 : EPSG registry >> 33000-200000 : ESRI registry >> other : CUSTOM/SRID >> >> Not sure why you distinguish SRID from CUSTOM. Have they different >> meaning/usage ? >> >> Michaël >> >> >> Le 03/09/2016 à 19:43, Giuseppe Aruta a écrit : >>> Maybe I should correct on this way - to save compatibility with >>> geotif >>> >>> Code : >>> >>> integer >>> EPSG : [2000..32767] or [5999999..2147483647] >>> ESRI : [32999..200000] >>> GEOTIF PROJECTION: [1..28]* >>> CUSTOM : [29..1999] or [32769..32999] or [200000..6999999] >>> NOT DEFINED: [-1] >>> USER DEFINED: [0] or [32768] >>> >>> not integer >>> IGNF: >>> >>> * See >>> http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/GeoTiff.html >>> <http://www.sno.phy.queensu.ca/%7Ephil/exiftool/TagNames/GeoTiff.html>. >>> The geotif method in Proj Utils class, in the GeoKeyDirectoryTag, >>> scans geographic/geocentric projection if no projected value is >>> recognized >>> >>> Peppe >>> >>> 2016-09-03 12:22 GMT+02:00 Giuseppe Aruta >>> <giuseppe.ar...@gmail.com <mailto:giuseppe.ar...@gmail.com>>: >>> >>> I understand. I don't do any work today. And wait for your >>> commits >>> Peppe >>> >>> 2016-09-03 12:01 GMT+02:00 Michaël Michaud >>> <m.michael.mich...@orange.fr >>> <mailto:m.michael.mich...@orange.fr>>: >>> >>> Hi Peppe, >>> >>> If you're not changing ProjUtils class today, I'll make >>> some refactoring. >>> Would be nice if you can double check after my commit. >>> >>> About test on srid integer, there is not much of a >>> problem. Just a small inconsistency betwwen comment and >>> code on CUSTOM authority >>> >>> Comment : >>> CUSTOM : [200000..209199] >>> >>> Code : >>> EPSG : ]-∞..32768[ or ]5999999..2147483647] >>> ESRI : ]32999..200000[ >>> CUSTOM : [32768..32999] or [200000..5999999] >>> >>> Michaël >>> >>> >>> Le 02/09/2016 à 16:00, Giuseppe Aruta a écrit : >>>> Hi Michaël, >>>> thanks for the suggestions. >>>> >>>> >srid.txt encoding >>>> I upgraded SVN repository with a UTF-8 version. >>>> >>>> >I noticed that tests done on the srid integer value are >>>> not consistent between the comments and the code. >>>> Sorry. I am still not familiar with some developing >>>> terminology (and the usage of Java). >>>> Does it means I should remove those comments from that >>>> position? >>>> >>>> >ProjUtils is a very big class and contains redundant code >>>> Yes. During the long syage of thge class I added many >>>> extra code. Right now I realized that >>>> readSRSFromAuxiliaryFile_1 method was not used (and I >>>> removed from repository). I will use your suggestions >>>> and make it simpler and smaller, following OJ philosophy. >>>> >>>> Thanks again >>>> >>>> Peppe >>>> >>>> 2016-09-02 0:05 GMT+02:00 Michaël Michaud >>>> <m.michael.mich...@orange.fr >>>> <mailto:m.michael.mich...@orange.fr>>: >>>> >>>> Hi Peppe, >>>> >>>> Thanks for the work. Here are some suggestions. >>>> >>>> I noticed that tests done on the srid integer value >>>> are not consistent between the comments (and the >>>> referenced site >>>> >>>> http://help.arcgis.com/en/arcgisserver/10.0/apis/soap/whnjs.htm#SOAP_Geometry_FindSRByWKID.htm >>>> >>>> <http://help.arcgis.com/en/arcgisserver/10.0/apis/soap/whnjs.htm#SOAP_Geometry_FindSRByWKID.htm>) >>>> and the code. >>>> >>>> Also I think there is a problem with srid.txt >>>> encoding (with the addition of IGNF registry which >>>> includes non ASCII characters). I suggest that we >>>> code the file in UTF-8 (it is currently recognized >>>> as ISO 8859-1 by my IDE) and read it as UTF-8 so >>>> that it behaves similarly on windows or linux (using >>>> *InputStreamReader >>>> >>>> <http://docs.oracle.com/javase/8/docs/api/java/io/InputStreamReader.html#InputStreamReader-java.io.InputStream-java.lang.String->**(**InputStream >>>> >>>> <http://docs.oracle.com/javase/8/docs/api/java/io/InputStream.html>**in,**String >>>> >>>> <http://docs.oracle.com/javase/8/docs/api/java/lang/String.html>** >>>> charset*Name)) >>>> >>>> ProjUtils is a very big class and contains redundant >>>> code. Maybe a few helper methods would help >>>> - getSRSDef(int srid) // to get SRSDef from SRID >>>> (computed 3 times in the file) >>>> - normalizeSRSName(String srs) // to normalize >>>> SRSName writing (whitespaces, separators...) >>>> - getSRSDef(String prjName) // read from srid.txt >>>> ... >>>> >>>> In readSRSFromAuxiliaryFile_1 and >>>> readSRSFromAuxiliaryFile methods, tests could be >>>> organized this way >>>> >>>> projectSourceFilePrj >>>> projectSourceRFilePrj // not used in >>>> readSRSFromAuxiliaryFile_1 >>>> projectSourceRFileAux >>>> >>>> // List<String> fileList : useless ! >>>> >>>> if (projectSourceFilePrj.exists()) {/**/} >>>> else if (projectSourceRFilePrj .exists()) {/**/} >>>> else if (projectSourceRFileAux.exists()) {/**/} >>>> else >>>> >>>> // if (!prjname.isEmpty()) {/* */} : no more needed >>>> if you wrote a getSRSDef(String prjName) method >>>> >>>> Michaël >>>> >>>> >>>> Le 01/09/2016 à 07:23, Giuseppe Aruta a écrit : >>>>> Hi all, >>>>> sorry for the long time I took to answer. >>>>> I understood the difficulties. My idea was limited >>>>> to work on the measurement part of Coordinate >>>>> systems (something that I started to do on my >>>>> Measurement plugin). The reprojection part was put >>>>> aside. >>>>> After reading the opinions of all, I decided to >>>>> abandon the idea to a add projection ID to the Task >>>>> and to limit the work in small steps only at layer >>>>> level, without core modifications. >>>>> I added to projection detection of layers >>>>> (LayerProperty and RasterLayerProperty plugins) the >>>>> capability to show the relative measure unit. >>>>> It was easy as it required only some extra info on >>>>> the SRID registry file >>>>> (org.openjump.core.ccordsys.utils.srid.txt) >>>>> In the future I will work on modified (measurement, >>>>> zoom, scale) plugin that detect that measure unit , >>>>> Measure Plugin will remain the main place for this >>>>> work. >>>>> Best regards >>>>> Peppe >>>>> >>>>> @Michael I added on SRID registry file also IGNF >>>>> and IGN Gèoportail codes, trying to set the most >>>>> possible common "synonimous". But I didn't test it >>>>> as I didn't find datas on that Authority. Could you >>>>> give a quick look, please. I took the informaion >>>>> ffor IGN Gèoportail form this page >>>>> (http://www.wms.lautre.net/projgp.html >>>>> <http://www.wms.lautre.net/projgp.html> - 2011) >>>>> >>>>> 2016-08-04 23:32 GMT+02:00 Michaël Michaud >>>>> <m.michael.mich...@orange.fr >>>>> <mailto:m.michael.mich...@orange.fr>>: >>>>> >>>>> Hi Peppe, >>>>> >>>>> Your explanation is clear. >>>>> >>>>> I tend to be on the same opinion as Jukka on >>>>> this topic because I >>>>> generally use OpenJUMP as a toolbox, and I >>>>> generally know exactly what I >>>>> want to do with my data. >>>>> >>>>> But I admit that to visualize heterogeneous >>>>> data, OpenJUMP has not much >>>>> to offer to the user to solve projection >>>>> problems, and the beginner can >>>>> be bothered by the lack of assistance. >>>>> >>>>> Here are a few recommandation : >>>>> >>>>> 1 - Projection issues may be tricky. It is >>>>> magic as long as the only >>>>> need is visualization, but if the user need to >>>>> reproject his dataset, he >>>>> must be aware of the consequences >>>>> (reversibility, topology >>>>> consistency...). Last time I have been screwed >>>>> by a projection problem >>>>> is with FME. I imported shapefiles with a prj >>>>> in a project using the >>>>> "same" projection. It was supposed to be a >>>>> no-op (doing nothing), except >>>>> that FME did a transformation from projection A >>>>> (defined by prj >>>>> parameters) to projection A (defined by >>>>> internal FME parameters), which >>>>> resulted in an invisible switch of a few >>>>> micrometers difficult to see, >>>>> but which broke the consistency with another >>>>> layer (which did not follow >>>>> the same process). Of course this can be >>>>> avoided in FME, but this is >>>>> just an example to illustrate that without a >>>>> great care, something >>>>> supposed to be magic may become dramatic. >>>>> >>>>> 2 - From my point of view, one of the most >>>>> difficult problem is to be >>>>> able to recognize that two coordinate reference >>>>> system with different >>>>> origins (different registries, different >>>>> formats, different libraries, >>>>> different definitions) represent the same thing >>>>> (see the above problem >>>>> with FME). I think you already worked on that >>>>> problem. >>>>> >>>>> 3 - Your mail explains quite clearly what >>>>> already exists and where you >>>>> want to go. I think that to anticipate >>>>> difficulties, we can suppose that >>>>> a SRID is associated to the task and try to >>>>> define OpenJUMP behaviour in >>>>> different situations : >>>>> - default behaviour when creating a new task : >>>>> asking for a srid or not >>>>> ? it is a good thing if OJ can infer >>>>> information from prj files or other >>>>> sources, but I don't like having to answer >>>>> esoteric questions before I >>>>> can start working. >>>>> - task without srid : does it take the srid of >>>>> the first layer imported >>>>> ? What if layers without srid are already >>>>> imported ? >>>>> - can we change the srid of a task if layers >>>>> with srid are already >>>>> imported ? >>>>> - importing a layer with a different srid : 1) >>>>> the layer is just tagged >>>>> (layer srid mismatch task srid), 2) the layer >>>>> is automatically >>>>> reprojected by the renderer ? 3) the user is >>>>> invited to reproject the >>>>> layer ? 4) There are some options to define >>>>> OpenJUMP behaviour >>>>> - how to deal with layers without projection : >>>>> can we import them in a >>>>> task with a srid ? can we edit them ? Do we set >>>>> the task projection to >>>>> the layer projection automatically ? >>>>> - if a reprojected layer is not editable, an >>>>> interesting option would be >>>>> to set the task srid to the selected layer srid >>>>> (-> makes the selected >>>>> layer editable, and reproject other layers) >>>>> - etc. >>>>> >>>>> 4- Implementation : no real opinion. Ede's >>>>> advice will certainly make >>>>> the code more flexible, but also a bit more >>>>> complex. And how to >>>>> represent the coordinate system property ? >>>>> Another difficult question. >>>>> We already have SRID represented by an int at >>>>> the geometry level (JTS) >>>>> and a CoordinateSystem at the FeatureSchema >>>>> level. IMHO, the first is a >>>>> bit too lightweight (cannot handle non EPSG >>>>> crs). The second is too >>>>> lightweight if we want to use it to effectively >>>>> transform coordinates >>>>> (cannot handle much transformations) and too >>>>> heavyweight if we just use >>>>> it as a reference to be used by CTS library (or >>>>> any other). >>>>> >>>>> >>>>> My 3 cents >>>>> >>>>> Michael >>>>> >>>>> >>>>> >>>>> Le 03/08/2016 à 15:13, Gmail a écrit : >>>>> > LoopThis thread needs a larger explanation. >>>>> > I try to simplify it. >>>>> > other GIS like Kosmo or GVSig implemented >>>>> Coordinate system framework >>>>> > following these steps: >>>>> > a) first step they add a projection object to >>>>> the task (usually as EPSG or >>>>> > ESRI code). In Kosmo user has to set that. >>>>> QGIS also allows to set Task >>>>> > projection loading that from the first >>>>> loadedf file (with SRID). >>>>> > b) QGIS define the Unit of the task from SRID >>>>> ( ex. 4326>degree, >>>>> > 32632>metre) while GvSig And Kosmo require to >>>>> set it manually. >>>>> > c) a projection object is set to each loaded >>>>> layer. This is done reading >>>>> > layer metadata or manually >>>>> > d) if the task and the layer projection >>>>> object are different a >>>>> > transformation should be set. Those software >>>>> use ( for vector) proj4 >>>>> > libraries. In this step Qgis and newer gvsig >>>>> allows on fly reprojection. >>>>> > e) this transformation is taken into account >>>>> only by layer renderes on the >>>>> > workbench. Which changes geometry before >>>>> drawing it. >>>>> > This transformation is saved into project >>>>> file and taken into account >>>>> > whenever the project file is loaded. >>>>> > f) Note that Kosmo (and probably Gvsig) >>>>> doesn't allow any spatial operation >>>>> > on reprojected layers. The only way to modify >>>>> them is to save them reprojected. >>>>> > >>>>> > Recently I did few modifications on shape >>>>> file reading in order to expand >>>>> > capability to set layer SRId when reading >>>>> file. Layer properties plugins >>>>> > already have this capability for both raster >>>>> and vector ( included >>>>> > geotif*). Together with database and wfs >>>>> capability to record layer srid we >>>>> > probably get almost point C of my list. >>>>> > >>>>> > My idea is to work on point A and B, >>>>> integrating parts if my measure plugin >>>>> > in to OJ core in order to have >>>>> measurements\zoom when task projection is >>>>> > geographic or possibility that oj display >>>>> meter or feet unit on >>>>> > measurements \ scale bar. >>>>> > The other points can be faced in the future, >>>>> including in fly reprojection. >>>>> > >>>>> > My project: >>>>> > 1) Oj already as a srid registry embedded >>>>> that I added when I defined srid >>>>> > detection capability from auxiliary files. It >>>>> is a simple list of >>>>> > projection, a series of lines with only srid >>>>> number and a proj. description >>>>> > ( ex <32632>;<WGS 84 UTM zone 32>), build >>>>> using proj4 registries and excel. >>>>> > I could expand each line with unit ( ex >>>>> <32632>;<WGS 84 UTM zone 32>;<metre>) >>>>> > 2) expand Task class with srid code and unit. >>>>> User can define manually . >>>>> > 3) modify measure /zoom plugins according >>>>> units, meter, foot, degree ( in >>>>> > this last case I would limit only to wgs84 ) >>>>> using classes fro my measure >>>>> > plugin. >>>>> > >>>>> > Peppe >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > * >>>>> > >>>>> > >>>>> > >>>>> > Inviato con AquaMail per Android >>>>> > http://www.aqua-mail.com >>>>> > >>>>> > >>>>> > Il 03 agosto 2016 12:32:48 >>>>> edgar.sol...@web.de >>>>> <mailto:edgar.sol...@web.de> ha scritto: >>>>> > >>>>> >> hey Peppe, >>>>> >> >>>>> >> On 03.08.2016 11 <tel:03.08.2016%2011>:11, >>>>> Giuseppe Aruta wrote: >>>>> >>> Hi all, >>>>> >>> The title explains what is my idea. In a >>>>> possible future we can extend OJ >>>>> >>> projection capabilities. And the 1st step I >>>>> would explore is to add SRID >>>>> >>> code to a task (to centralize possible >>>>> transformations) >>>>> >> can you elaborate? >>>>> >> >>>>> >>> and unit of measurements (retriving from >>>>> SRID, which will affect other >>>>> >>> plugins/tools like measure tools, measure >>>>> area/length, display scales etc, >>>>> >>> especially for Geographic coordinate systems). >>>>> >> same here. >>>>> >> >>>>> >>> I gave a look at Task class , should I >>>>> implement (srid and unit) as >>>>> >>> properties into the associate xml file? >>>>> Does it breaks compatibility? >>>>> >> ..ede >>>>> >> >>>>> >> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >> _______________________________________________ >>>>> >> Jump-pilot-devel mailing list >>>>> >> Jump-pilot-devel@lists.sourceforge.net >>>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>>> >> >>>>> >>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>>> >>>>> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> >>>>> > >>>>> > >>>>> > >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> > _______________________________________________ >>>>> > Jump-pilot-devel mailing list >>>>> > Jump-pilot-devel@lists.sourceforge.net >>>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>>> > >>>>> >>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>>> >>>>> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> >>>>> > >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Jump-pilot-devel mailing list >>>>> Jump-pilot-devel@lists.sourceforge.net >>>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>>> >>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>>> >>>>> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Jump-pilot-devel mailing list >>>>> Jump-pilot-devel@lists.sourceforge.net >>>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>>> >>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>>> >>>>> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Jump-pilot-devel mailing list >>>> Jump-pilot-devel@lists.sourceforge.net >>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>> >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>> >>>> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Jump-pilot-devel mailing list >>>> Jump-pilot-devel@lists.sourceforge.net >>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>> >>>> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ Jump-pilot-devel >> mailing list Jump-pilot-devel@lists.sourceforge.net >> <mailto:Jump-pilot-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel ------------------------------------------------------------------------------ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel ------------------------------------------------------------------------------ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
