which svg symbols are needed?

[Michat]

Thank you JohanG categorizing that set of symbols in the wiki.

Currently I'm focused in FG bagdes designs, and I have still no time to upload the rest of VFR symbols rasters. The fact that today I've entered into my aepcam (wiki user page) where I have my sand box, but surprisingly someones has removed it. , happens that I use my user web page as a sandbox ( as suggested) in order to control those VFR symbols - legend information, that then could be used for an specific wiki page. With that content removed will be hard to me to control what is the next symbol I have to upload in order to complete all set. Getting the feeling that somebody has opened my deskbox. removing a precious information to me.

Returning to the work categorizing wiki I suggest to create an IFR Chart Symbols category due that also the IFR charts symbols set based on Jeppessen is really finished and released as svg too (via Hyde user). So in the next future we can raster them for wiki, and or to offer a svg file for each symbols. So the reader can find documentation and the developer can get graphic resources.

Amicalement.


FlightGear "The one that Peace supports.

[Hooray]

Hola Michat !

Please, no hurry.
Regarding the VFR images, maybe I am missing something but there should be no need to actually upload all those to the wiki ?

Like I mentioned elsewhere, you have been doing quite some redundant work here, and I'd suggest to follow the advice given earlier to keep your workload low:

http://wiki.flightgear.org/File_talk:Ra ... ithrwy.png
Subject: which svg symbols are needed?

Here's some guidelines for people wanting to help with SVG images specifically for Canvas to avoid unnecessary work:

• please use transparent backgrounds
• no need to provide different labels/translations or fonts (can be done by Nasal/Canvas)
• no need to provide different scales of symbols (can be done by Nasal/Canvas!)
• no need to provide differently colored symbols (can be done by patching svg.nas to allow elements to be looked up !)
• no need to provide different combinations of overlaid symbols (can be done by Nasal/Canvas via z-index!)

However, if you want something to be configurable, one important thing is having an element ID that we can refer to, in order to look up the key and modify the symbol via Nasal.
Without having an element id (e.g. for labels) we cannot easily modify such SVG images procedurally.

For the time being, I believe having a single SVG file in $FG_ROOT that contains all primitives/symbols should be sufficient - if somebody needs the symbol to present on the wiki, they can still upload the symbol as a raster image. Otherwise, I'd just ask Hyde to commit your changes to $FG_ROOT so that contributors can easily find and use those symbols.

[Gijs]

The fact that today I've entered into my aepcam (wiki user page) where I have my sand box, but surprisingly someones has removed it.

Huh? http://wiki.flightgear.org/User:Aepcam/ ... rt_Symbols

[Hooray]

I still think that there are too many variations in size/scale, font, color and overlays that should really not be done manually via Inkscape but be handled procedurally via Nasal/Canvas. This must have been a lot of work already, and I think it would be better to honor the advice given earlier to focus really on just the "primitives", so that any variations of symbols would be procedurally created at run-time. Sorry if my wording is too technical, but maybe some Spanish-speaking contributor could translate this, so that there's no misconception and so that we don't end up with a ton of such symbols that would really be better handled by Nasal & Canvas directly.
Personally, the main use-case I can see is within $FG_ROOT, not necessarily as part of the wiki - even though other FG related projects/websites may benefit from having such a symbol set (e.g. MPMap).

[Michat]

I'm getting older.

[Johan G]

The fact that today I've entered into my aepcam (wiki user page) where I have my sand box, but surprisingly someones has removed it. , happens that I use my user web page as a sandbox ( as suggested) in order to control those VFR symbols - legend information, that then could be used for an specific wiki page. With that content removed will be hard to me to control what is the next symbol I have to upload in order to complete all set. Getting the feeling that somebody has opened my deskbox. removing a precious information to me.

Huh? http://wiki.flightgear.org/User:Aepcam/ ... rt_Symbols

I noted that while the sandbox with the symbols still is there, someone deleted your user page (the only edit was that someone else had used it as discussion page). Just start the page over again and add a link to your list of symbols and you will find it a bit faster.

Returning to the work categorizing wiki I suggest to create an IFR Chart Symbols category...

Done.

[Michat]

Thank you JohanG.

However, pointing Hooray's words : "Regarding the VFR images, maybe I am missing something but there should be no need to actually upload all those to the wiki ?" it seems that is not so important.

Guys, What is you opinion about it ?. I think those rasters could make part of an specific wiki page in order to use it as a legend for pilot consulting, same with the IFR set, like IVAO an VATSIM have release in pdf format.

I'ts a long task due to the huge amount of symbols and legends but the hardest task is done as the symbols already been drawn following the scale and original colors of the public manuals AOPA's And Jeppessen. So i though is was a good moment to export them on the go in order to use in the wiki.

Open to your suggestions.



Amicalement.


Note: I'll be out of the cockpit from 7 July to 7 September. As every year I travel to the mediterranean coast where I work as sailboarding monitor specialist, like FG a great passion for me.

Little be off topic, this is the way we fly. Same spirit that I found in FlightGear. Hope you enjoy the video.

[Hooray]

Well, I don't know - but even if we're going to create such a "reference" at some point, I'd expect something like that to be procedurally created, i.e. through LaTex using the original SVG files. Maintaining such things manually is a lot of work.

Personally, I'd suggest to focus on images for which we have an immediate need, such as those symbols that are needed to port the hard-coded Map dialog to Canvas - currently, it's just an ILS/LOC symbol that we're missing there IIRC. Many of the other symbols will certainly come in handy at some point - but here, the problem is that we'll first of all need the corresponding layers, which really require placement information to actually make use of such symbols. A "sectional" overlay will usually be much easier to integrate/adapt and use IMO.

Overall, I don't see anything wrong with having such "references", but in general, I'd probably suggest to favor the DRY-principle, in the sense that it will be more future-proof, and less maintenance work, to simply collect links to useful resources (e.g. FAA manuals/references etc) - we cannot possibly duplicate all that info and expect it to stay up to date. Then again, on the FG side of things, we clearly have several valid use-cases to include libraries with image sets for all the different kinds of maps, dialogs and MFD instruments. But from a workload standpoint, I'd suggest to focus on/prioritize requests that have some kind of "immediate" need/use-case. And from our standpoint, it would make sense to honor the SVG creation guidelines that have been mentioned various times, i.e. to ensure that things can be properly used by Canvas, without any unnecessary work.

[Michat]

Howdy folks..

I have update the IFR set based with ILS loc symbols ( those triangular symbols missing) that tomorrow I'll send to Hyde. (sent now)

About the other questions Hooray, is up to you as you guys know better than me what is the best way to control such huge info, with you magic tools.

Think about I'm very limited such using an almost full hard disk as well using "under magnetic field old laptop (Maglev)", but mainly because I have no previous experience designing soft, even I had no time to understand how inkscape works.

To be honest, today I spent some time trying to find info to fit your requirements.

File document info shows that background is transparent. But I see white back ground (not when exporting to a raster).
I found that grouped symbols can have and ID. I'm terrible with database numbers.

About dimensions I always thought that those were the most important things, because there is an inherit size/scale relation between them created by Air Agencies.. No matter if you then change size via hack, the relation still must be there.

About the color, that a precious information. No matter if you then change via hack, but colors are really important. So I though necessary in to transmit this info.

Please thing this is not a discussion, better than me you know what you need, happens that I have low response mode activated. Your are unmatched faster than me, language being not insurmountable barrier, sometimes the pc blows up all text I write by magic electrostatic, sometimes I get slow and confused, furthermore today I get a file corruption error from inkscape, almost causing me another shock. Take it easy Michat.


Okay I'm here to help and be helped, my method is intuitive. Sometimes (usually) I need time to process info.

Amicalement