#350: build_html_index.sh: put photo modules in imagery section
---------------------+------------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: task | Status: new
Priority: minor | Milestone: 6.4.0
Component: Docs | Version: svn-develbranch6
Resolution: | Keywords: man help build
Platform: All | Cpu: All
---------------------+------------------------------------------------------
Comment (by glynn):
Replying to [ticket:350 hamish]:
> the photo.* modules should be listed at the end of the imagery module
section in imagery.html and full_index.html.
> I'm not sure how to do that..
The build_html_index.sh iterates over prefixes, generating one HTML file
for each prefix. You would need to significantly change the script to
allow multiple prefixes in a single HTML file.
In any case, I'm not sure that these modules should even appear in the
index, as they're only usable via i.ortho.photo. IMHO, the indices should
only list user-visible modules in $GISBASE/bin and $GISBASE/scripts, not
the utility modules in $GISBASE/etc. The latter should be referenced from
the manual of the module(s) which invoke them.
#350: build_html_index.sh: put photo modules in imagery section
---------------------+------------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: task | Status: new
Priority: minor | Milestone: 6.4.0
Component: Docs | Version: svn-develbranch6
Resolution: | Keywords: man help build
Platform: All | Cpu: All
---------------------+------------------------------------------------------
Comment (by hamish):
Replying to [comment:1 glynn]:
> The build_html_index.sh iterates over prefixes, generating one
> HTML file for each prefix. You would need to significantly
> change the script to allow multiple prefixes in a single HTML
> file.
hence this ticket.
> In any case, I'm not sure that these modules should even appear
> in the index, as they're only usable via i.ortho.photo. IMHO,
> the indices should only list user-visible modules in $GISBASE/bin
> and $GISBASE/scripts, not the utility modules in $GISBASE/etc.
> The latter should be referenced from the manual of the module(s)
> which invoke them.
In the case of i.ortho.photo, it seems to me that the submodules could all
be renamed i.* and i.ortho.photo replaced with their own enumerated
submenu from the Imagery menu in the GUI.
#350: build_html_index.sh: put photo modules in imagery section
---------------------+------------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: task | Status: new
Priority: minor | Milestone: 6.4.0
Component: Docs | Version: svn-develbranch6
Resolution: | Keywords: man help build
Platform: All | Cpu: All
---------------------+------------------------------------------------------
Comment (by glynn):
Replying to [comment:2 hamish]:
> > In any case, I'm not sure that these modules should even appear
> > in the index, as they're only usable via i.ortho.photo. IMHO,
> > the indices should only list user-visible modules in $GISBASE/bin
> > and $GISBASE/scripts, not the utility modules in $GISBASE/etc.
> > The latter should be referenced from the manual of the module(s)
> > which invoke them.
>
> In the case of i.ortho.photo, it seems to me that the submodules could
all be renamed i.* and i.ortho.photo replaced with their own enumerated
submenu from the Imagery menu in the GUI.
Right. If you rename them to i.photo.*, they would appear alongside other
imagery modules in the indices. As i.ortho.photo itself is nothing more
than a menu, it may as well be removed in 7.0.
FWIW, I really don't agree with changing any of this in 6.x.
#350: build_html_index.sh: put photo modules in imagery section
----------------------+------------------------------
Reporter: hamish | Owner: grass-dev@…
Type: task | Status: closed
Priority: minor | Milestone: 6.4.0
Component: Docs | Version: svn-develbranch6
Resolution: wontfix | Keywords: man help build
CPU: All | Platform: All
----------------------+------------------------------
Changes (by wenzeslaus):
* status: new => closed
* resolution: => wontfix
Comment:
Replying to [comment:4 neteler]:
> Closing as wontfix?
Yes. Closing because these modules were dropped and perhaps there is no
big need for reintroducing them since there are other projects such as
[http://opendronemap.org/ OpenDroneMap]
(https://github.com/OpenDroneMap/OpenDroneMap). If any modules with
similar focus are (re-)introduced in 7+, they will be properly named with
proper interface (e.g. no menu module hiding useful command line tools),
so this ticket would be invalid anyway. For 6.4, there is no need for
changing anything in this direction.